Comment: Keyword: From GLOBAL sites as quickly as possible in a SINGLE S3 bucket. Minimize operational complexity A. is correct because S3 Transfer Acceleration is support for high speed transfer in Edge location and you can upload it immediately. Also with multipart uploads your big file can be uploaded in parallel. B, C, D. is not minimize operational and fast when compare to answer A
Comment: A is true answer
Comment: General line: Collect huge amount of the files across multiple continents Conditions: High speed Internet connectivity Task: aggregate the data from all in a single S3 bucket Requirements: as quick as possible, minimize operational complexity Correct answer A: S3 Transfer Acceleration because: - ideally works with objects for long-distance transfer (uses Edge Locations) - can speed up content transfers to and from S3 as much as 50-500% - use cases: mobile & web application uploads and downloads, distributed office transfers, data exchange with trusted partners. Generally for sharing of large data sets between companies, customers can set up special access to their S3 buckets with accelerated uploads to speed data exchanges and the pace of innovation. B - about disaster recovery C - about transferring data between your local environment and the AWS Cloud D - about disaster recovery
Comment: C, we DO have a "local environment" (a "site") that collect data, and THAT data must go to "the AWS cloud". Why not C? The stem says nothing about large objects, which would be a requirement for the "multipart upload" that is mentioned.
Comment: Company has high speed internet and requires less operational complexity, hence option A
Comment: Explanation: Option B suggests uploading the data from each site to an S3 bucket in the closest Region. This ensures that the data is transferred quickly over high-speed Internet connections. By using S3 Cross-Region Replication, the objects can be automatically copied to the destination S3 bucket, allowing for easy aggregation. Once the data is successfully replicated, it can be removed from the origin S3 bucket to minimize storage costs and reduce complexity. Option A is not the best choice because it only focuses on optimizing the upload to the destination S3 bucket by using S3 Transfer Acceleration and multipart uploads. However, it doesn't address the requirement of aggregating data from multiple sites.
Comment: But B requires manual intervention (removal from original bucket), that does meet the 'minimize operational complexity' requirement.
Comment: A specifically mentions "multipart upload", but the stem says nothing about large files. We have "sites" that collect a lot of sensor data. Wouldn't C be an option? Snowball Edge is tied to a region, so it can't upload directly to the central bucket. Copying the files onto Snowball Edge, then let Snowball Edge upload them to a bucket in its own region from where they would be replicated to the central bucket. This would meet the requirement of minimizing operational overhead. (Options B and D are clearly out as they require manual intervention.)
Comment: The Snowball family is used for petabyte-scale migrations so using Snowball is overkill. You can simply use transfer acceleration AND multi-part uploads to speed up S3 uploads as they are already features of the service.
Comment: i think cause of "min operation work and costs "
Comment: B: Cross region replication attracts extra costs to transfer data across regions. No need to choose this option as each site is having high speed connection. C. No need to go for device transfers as each site is having high speed connection. D. Not a good solution to use EBS volumes as we can transfer the data directly to S3. A is the best answer, especially going with multi-part upload, transferring the data to the destination bucket using transfer accelerator.
Comment: A. Despite this option can be valid, it implies a bit of operational overhead compared with other options. Additionally, there is no need to aggregate that change to the existing architecture because we are already working in S3, and using other storage services incurs unnecessary costs. B. To collect the logs, we use CloudTrail over CloudWatch. Running SQL queries from the Amazon CloudWatch console is not recommended for this use case, since it is more used for filtering. C. Athena integrates seamlessly with S3 and allows you to run simple SQL queries in no time. When working with Apache Spark or with SQL in S3, using this service is the best option. D. This option incurs elevated operational overhead. Glue is not used to catalog the logs. Analyzing logs with Spark on an EMR cluster is very common, but you can do it faster with the Athena service integrated with S3 directly.
Comment: A. S3 transfer Accel is best option i think
Comment: The key is minimising operational complexity --> Ans A: doesn't need intermediate storage, additional infrastructure, minimises operations with direct path to S3 bucket.
Comment: A is the answer.
Comment: A is correct answer.
Comment: A for sure
Comment: doesn't need intermediate storage or additional infrastructure thus, minimizing operational complexity providing faster direct path to destination S3 bucket.
Comment: A is most right
Comment: other was operational overhead except A
Comment: S3 Transfer Acceleration is the best solution cz it's faster , good for high speed, Transfer Acceleration is designed to optimize transfer speeds from across the world into S3 buckets.
Comment: A. S3 Transfer Acceleration will do the required job B. it will be appropriate only when durability and availability across location C. Snowball will be better option only when multiple Terabyte of data needs to be copied D. Additional overhead of using EC2 instance and storing EBS volume, taking snapshot to stone finally on S3
Comment: Answer: C Amazon Athena is an interactive query service that makes it easy to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL. With a few actions in the AWS Management Console, you can point Athena at your data stored in Amazon S3 and begin using standard SQL to run ad-hoc queries and get results in seconds.
Comment: I agree C is the answer
Comment: C is right.
Comment: Keyword: - Queries will be simple and will run on-demand. - Minimal changes to the existing architecture. A: Incorrect - We have to do 2 step. load all content to Redshift and run SQL query (This is simple query so we can you Athena, for complex query we will apply Redshit) B: Incorrect - Our query will be run on-demand so we don't need to use CloudWatch Logs to store the logs. C: Correct - This is simple query we can apply Athena directly on S3 D: Incorrect - This take 2 step: use AWS Glue to catalog the logs and use Spark to run SQL query
Comment: Amazon Athena helps you analyze unstructured, semi-structured, and structured data stored in Amazon S3. Examples include CSV, JSON, or columnar data formats such as Apache Parquet and Apache ORC. You can use Athena to run ad-hoc queries using ANSI SQL, without the need to aggregate or load the data into Athena. It uses Amazon QuickSight for data visualization AWS Glue Data Catalog allows you to create tables and query data in Athena based on a central metadata store available
Comment: To meet the requirements of analyzing log files stored in JSON format in an Amazon S3 bucket with minimal changes to the existing architecture and minimal operational overhead, the most suitable option would be Option C: Use Amazon Athena directly with Amazon S3 to run the queries as needed. Amazon Athena is a serverless interactive query service that allows you to analyze data directly from Amazon S3 using standard SQL queries. It eliminates the need for infrastructure provisioning or data loading, making it a low-overhead solution. Overall, Amazon Athena offers a straightforward and efficient solution for analyzing log files stored in JSON format, ensuring minimal operational overhead and compatibility with simple on-demand queries.
Comment: A. Despite this option can be valid, it implies a bit of operational overhead compared with other options. Additionally, there is no need to aggregate that change to the existing architecture because we are already working in S3, and using other storage services incurs unnecessary costs. B. To collect the logs, we use CloudTrail over CloudWatch. Running SQL queries from the Amazon CloudWatch console is not recommended for this use case, since it is more used for filtering. C. Correct answer. Athena integrates seamlessly with S3 and allows you to run simple SQL queries in no time. When working with Apache Spark or with SQL in S3, using this service is the best option. D. This option incurs elevated operational overhead. Glue is not used to catalog the logs. Analyzing logs with Spark on an EMR cluster is very common, but you can do it faster with the Athena service integrated with S3 directly.
Comment: C. Athena lets you analyse S3 data using standard SQL. No other steps needed
Comment: C for sure
Comment: Using Amazon Athena with Amazon S3 is direct and efficient way for querying JSON log files with minimum operational overhead.
Comment: A, B, D operational overhead. C accept all requirement
Comment: Option A is correct Amazon Athena is an interactive query service provided by Amazon Web Services (AWS) that enables you to analyze data stored in Amazon S3 (Simple Storage Service) using standard SQL queries.
Comment: Answer should be C, Simple approach, Store logs in S3 and use Athena to query. Redshift will be costly approach.Cloudwatch does not store any data. So A and B ruled out.
Comment: S3 + Athena is simples approach
Comment: C seems right.
Comment: Amazon Athena, because it provides the easiest way to run simple SQL service on a on-demand basis on an S3 bucket. The data is not complex so Redshift and EMR are a overhead or simply not suitable. CloudWatch does not have a console where you can run queries.
Comment: C seems to be fine
Comment: No need to build a server and it is on the fly
Comment: Amazon Athena is an interactive query service that makes it easy to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL. With a few actions in the AWS Management Console, you can point Athena at your data stored in Amazon S3 and begin using standard SQL to run ad-hoc queries and get results in seconds.
Comment: aws:PrincipalOrgID Validates if the principal accessing the resource belongs to an account in your organization.
Comment: the condition key aws:PrincipalOrgID can prevent the members who don't belong to your organization to access the resource
Comment: Condition keys: AWS provides condition keys that you can query to provide more granular control over certain actions. The following condition keys are especially useful with AWS Organizations: aws:PrincipalOrgID – Simplifies specifying the Principal element in a resource-based policy. This global key provides an alternative to listing all the account IDs for all AWS accounts in an organization. Instead of listing all of the accounts that are members of an organization, you can specify the organization ID in the Condition element. aws:PrincipalOrgPaths – Use this condition key to match members of a specific organization root, an OU, or its children. The aws:PrincipalOrgPaths condition key returns true when the principal (root user, IAM user, or role) making the request is in the specified organization path. A path is a text representation of the structure of an AWS Organizations entity.
Comment: are we not choosing ou because the least overhead term was use? option B also seems correct
Comment: As there are many OU, you need more effort to list down OU path. And question mention about least management overhead to allow users in Organization, not single OU.
Comment: Exactly
Comment: use a new condition key, aws:PrincipalOrgID, in these policies to require all principals accessing the resource to be from an account (including the master account) in the organization. For example, let's say you have an Amazon S3 bucket policy and you want to restrict access to only principals from AWS accounts inside of your organization. To accomplish this, you can define the aws:PrincipalOrgID condition and set the value to your organization ID in the bucket policy. Your organization ID is what sets the access control on the S3 bucket. Additionally, when you use this condition, policy permissions apply when you add new accounts to this organization without requiring an update to the policy.
Comment: Answered by ChatGPT with an explanation. The correct solution that meets these requirements with the least amount of operational overhead is Option A: Add the aws PrincipalOrgID global condition key with a reference to the organization ID to the S3 bucket policy. Option A involves adding the aws:PrincipalOrgID global condition key to the S3 bucket policy, which allows you to specify the organization ID of the accounts that you want to grant access to the bucket. By adding this condition to the policy, you can limit access to the bucket to only users of accounts within the organization.
Comment: Option B involves creating organizational units (OUs) for each department and adding the aws:PrincipalOrgPaths global condition key to the S3 bucket policy. This option would require more operational overhead, as it involves creating and managing OUs for each department. Option C involves using AWS CloudTrail to monitor certain events and updating the S3 bucket policy accordingly. While this option could potentially work, it would require ongoing monitoring and updates to the policy, which could increase operational overhead.
Comment: Option D involves tagging each user that needs access to the S3 bucket and adding the aws:PrincipalTag global condition key to the S3 bucket policy. This option would require you to tag each user, which could be time-consuming and could increase operational overhead. Overall, Option A is the most straightforward and least operationally complex solution for limiting access to the S3 bucket to only users of accounts within the organization.
Comment: This is the least operationally overhead solution because it requires only a single configuration change to the S3 bucket policy, which will allow access to the bucket for all users within the organization. The other options require ongoing management and maintenance. Option B requires the creation and maintenance of organizational units for each department. Option C requires monitoring of specific CloudTrail events and updates to the S3 bucket policy based on those events. Option D requires the creation and maintenance of tags for each user that needs access to the bucket.
Comment: Option A proposes adding the aws PrincipalOrgID global condition key with a reference to the organization ID to the S3 bucket policy. This would limit access to the S3 bucket to only users of accounts within the organization in AWS Organizations, as the aws PrincipalOrgID condition key can check if the request is coming from within the organization.
Comment: B. Create an organizational unit (OU) for each department. Add the AWS: Principal Org Paths global condition key to the S3 bucket policy. This solution allows for the S3 bucket to only be accessed by users within the organization in AWS Organizations while minimizing operational overhead by organizing users into OUs and using a single global condition key in the bucket policy. Option A, adding the Principal ID global condition key, would require frequent updates to the policy as new users are added or removed from the organization. Option C, using CloudTrail to monitor events, would require manual updating of the policy based on the events. Option D, tagging each user, would also require manual tagging updates and may not be scalable for larger organizations with many users.
Comment: Keywords: - Company uses AWS Organizations - Limit access to this S3 bucket to only users of accounts within the organization in AWS Organizations - LEAST amount of operational overhead A: Correct - We just add PrincipalOrgID global condition key with a reference to the organization ID to the S3 bucket policy B: Incorrect - We can limit access by this way but this will take more amount of operational overhead C: Incorrect - AWS CloudTrail only log API events, we can not prevent user access to S3 bucket. For update S3 bucket policy to make it work you should manually add each account -> this way will not be cover in case of new user is added to Organization. D: Incorrect - We can limit access by this way but this will take most amount of operational overhead
Comment: Option A, which suggests adding the aws PrincipalOrgID global condition key with a reference to the organization ID to the S3 bucket policy, is a valid solution to limit access to the S3 bucket to users within the organization in AWS Organizations. It can effectively achieve the desired access control. It restricts access to the S3 bucket based on the organization ID, ensuring that only users within the organization can access the bucket. This method is suitable if you want to restrict access at the organization level rather than individual departments or organizational units. The operational overhead for Option A is also relatively low since it involves adding a global condition key to the S3 bucket policy. However, it is important to note that the organization ID must be accurately configured in the bucket policy to ensure the desired access control is enforced. In summary, Option A is a valid solution with minimal operational overhead that can limit access to the S3 bucket to users within the organization using the aws PrincipalOrgID global condition key.
Comment: AWS Identity and Access Management (IAM) now makes it easier for you to control access to your AWS resources by using the AWS organization of IAM principals (users and roles). For some services, you grant permissions using resource-based policies to specify the accounts and principals that can access the resource and what actions they can perform on it. Now, you can use a new condition key, aws:PrincipalOrgID, in these policies to require all principals accessing the resource to be from an account (including the master account) in the organization.
Comment: A. Correct answer. Bucket policy controls who can access to S3 and their objects. If we refer in the bucket policy to the organization, we can limit who can access inside that organization. B. Despite this option is correct, it is unnecessarily complex. We don't need to separate the AWS Organization users for the requirements imposed in the question. So, it only aggregates more operational overhead. C. Using CloudTrail for controlling the S3 access permissions is not suitable and require so many events to be monitored. Additionally, it only registers the logs, so CloudTrail cannot impose restrictions over the accounts that access to S3. D. Tagging each user is not an scalable or efficient solution since you need to tag every user in the infrastructure, which is probably not static. Additionally, it makes unnecessary verbose the S3 bucket policy associated to that bucket.
Comment: Ans A: LEAST amount of organisational overhead: instead of listing all accounts which are members of organisation, instead specify the orgn. ID in the Condition element
Comment: A for sure
Comment: The aws:PrincipalOrgID condition key allows you to restrict access based on the organization ID, ensuring that only principals (users, roles, etc.) from accounts within your AWS Organization can access the S3 bucket.
Comment: answer A is correct . Add the aws PrincipalOrgID global condition key with a reference to the organization ID to the S3 bucket policy.
Comment: EX: "arn:aws:iam::094697565646:user/Steve" Even if steve is added accidentally, he will not have access to financial data if he does not belong to the account in organization.As aws:PrincipalOrgID Validates if the principal accessing the resource belongs to an account in your organization.
Comment: PrincipalOrgID global condition is simples way to limit access BCD even if possible is too much work
Comment: Concurrent or at the same time key word for EFS
Comment: Ebs doesnt support cross az only reside in one Az but Efs does, that why it's c
Comment: And just for clarification to others, you can have COPIES of the same EBS volume in one AZ and in another via EBS Snapshots, but don't confuse that with the idea of having some sort of global capability that has concurrent copying mechanisms.
Comment: The answer is C. Copy the data from both EBS volumes to Amazon EFS. Modify the application to save new documents to Amazon EFS. The current architecture is using two separate EBS volumes, one for each EC2 instance. This means that each instance only has a subset of the documents. When a user refreshes the website, the Application Load Balancer will randomly direct them to one of the two instances. If the user's documents are not on the instance that they are directed to, they will not be able to see them.
Comment: To ensure that users see all of their documents at once, the solutions architect should propose Option C: Copy the data from both EBS volumes to Amazon EFS. Modify the application to save new documents to Amazon EFS. Option C involves copying the data from both EBS volumes to Amazon Elastic File System (EFS), and modifying the application to save new documents to EFS. Amazon EFS is a fully managed, scalable file storage service that allows you to store and access files from multiple EC2 instances concurrently. By moving the data to EFS and modifying the application to save new documents to EFS, the application will be able to access all of the documents from a single, centralized location, ensuring that users see all of their documents at once. Overall, Option C is the most effective solution for ensuring that users see all of their documents at once.
Comment: ***WRONG*** Option A involves copying the data so both EBS volumes contain all the documents. This option would not solve the issue, as the data is still stored on two separate EBS volumes, and the application would still need to read from both volumes to retrieve all of the documents. Option B involves configuring the Application Load Balancer to direct a user to the server with the documents. This option would not solve the issue, as the user may not always be directed to the server that has the documents they are looking for. Option D involves configuring the Application Load Balancer to send the request to both servers and return each document from the correct server. This option would not be an efficient solution, as it would require the application to send requests to both servers and receive and process the responses from both servers, which could increase the load on the application.
Comment: Keyword: second EC2 instance and EBS volume. They could see one subset of their documents or the other, but never all of the documents at the same time. EBS: attached to one instance (special EBS io1, io2 can attached to multiple instances but not much) EFS: can attached to multiple instances A: Incorrect - EBS volumes don't have function to copy data from running EBS volume to running EBS volume. B: Incorrect - We can use sticky session to forward same user to the same server but when user lose the session the user might be forward to another server. C: Correct - Because 2 instance now point to one EFS data storage, user will see both data. D: Incorrect - We only use Traffic Mirroring to sent request to both servers. Application Load Balancer don't support send request to both servers because it's design it balance workload between server. And also ALB cannot combine document from both servers and return.
Comment: Option A is not a good solution because copying data to both volumes would not ensure consistency of the data. Option B would require the Load Balancer to have knowledge of which documents are stored on which server, which would be difficult to maintain. Option C is a viable solution, but may require modifying the application to use Amazon EFS instead of EBS. Option D is a good solution because it would distribute the requests to both servers and return the correct document from the correct server. This can be achieved by configuring session stickiness on the Load Balancer so that each user's requests are directed to the same server for consistency. Therefore, the correct answer is D.
Comment: Sending requests to both servers can increase the response time since it would require checking two servers instead of one. Session stickiness only works if the user has data in only one of the servers; otherwise, it would continue missing data. Option C is not the best option, but is the one that fits better.
Comment: Ans C. Altho' A could do it, it would require a manual operation; the clue is "better scalability and availability" - EFS does that automatically
Comment: Correct Answer is C
Comment: C is correct answer.
Comment: C for sure
Comment: using Amazon EFS to provide a shared storage solution ensures that both EC2 instances can access the same documents, which resolves the issue of users seeing different subsets of documents depending on which instance they are connected to.
Comment: C is Correct whereas the purpose of Amazon EFS is to provide a scalable, shared, and fully managed file storage solution that seamlessly integrates with AWS services and meets the performance, availability, and durability requirements of modern applications.
Comment: The alternative is to use Aurora or DynamoDB with master-slave replication, otherwise EFS is the most logical.
Comment: EBS volumes must be in the same AZ as the instances they are attached to. So you cannot share an EBS across AZs. Unless you plan to have two separate volumes in each AZ, the simpliest solution is to use EFS as a shared file system that can be used across both AZs
Comment: Correct EBS can be used for one Az if you need the a solution which could be accessed across a AZ then go for File storage which is a regional service
Comment: If the idea is to keep documents in different places, then the only solution here is a file sharing system, EFS in this case
Comment: ABD are not even possible without further deails C is EFS which is shared volume.
Comment: Answer-c
Comment: Let's analyse this: B. On a Snowball Edge device you can copy files with a speed of up to 100Gbps. 70TB will take around 5600 seconds, so very quickly, less than 2 hours. The downside is that it'll take between 4-6 working days to receive the device and then another 2-3 working days to send it back and for AWS to move the data onto S3 once it reaches them. Total time: 6-9 working days. Bandwidth used: 0. C. File Gateway uses the Internet, so maximum speed will be at most 1Gbps, so it'll take a minimum of 6.5 days and you use 70TB of Internet bandwidth. D. You can achieve speeds of up to 10Gbps with Direct Connect. Total time 15.5 hours and you will use 70TB of bandwidth. However, what's interesting is that the question does not specific what type of bandwidth? Direct Connect does not use your Internet bandwidth, as you will have a dedicate peer to peer connectivity between your on-prem and the AWS Cloud, so technically, you're not using your "public" bandwidth. The requirements are a bit too vague but I think that B is the most appropriate answer, although D might also be correct if the bandwidth usage refers strictly to your public connectivity.
Comment: B is the correct answer because the migration needs to be completed as soon as possible with limited bandwidth
Comment: B is the correct answer
Comment: and it says, "The total storage is 70 TB and is no longer growing". Thats why it should be B.
Comment: I will add that the question does not specify if the company already has DA in place or not. If they don't have DA in place, it will take a long time (weeks) for DA connectivity to be setup. Another point for B here, as Snowball is much quicker from this perspective.
Comment: It does, because option D says "SET UP a DirectConnect connection", not "use an existing DirectConnect connection".
Comment: As using the least possible network bandwidth.
Comment: B is Correct Answer
Comment: The question states that the storage is no longer growing. This implies that we don't need to make any kind of data synchronization. Additionally, the total storage is 70 TB, which is a large amount of data. This implies high transfer costs. So, we can discard A, C and D options. Correct option: A. A Snowball device is a physical storage device which supports large data transfers. It is commonly used for transporting huge amounts of data from on-premises to AWS. Concretely, Snowball Edge is suitable for data transfers up to 80 TB. The transport times are between 1 and 2 weeks, so in case that we have hundreds of terabytes of data, we get them earlier than using Internet. In case that we need to transfer petabytes of data, it is recommended to use AWS Snowmobile, which is a physical track that transports data, up to 10 PB.
Comment: The correct answer is B not A, i misswrite that.
Comment: B is the correct answer
Comment: I choose B The key is: - The total storage is 70 TB and is no longer growing. - Using the least possible network bandwidth. No longer Growing mean 1 time migrate, no need file gw Least Possible Nw Bandwith --> Snowball Edge
Comment: Ans B. Agree: Snowball Edge is designed for these types of operations; its more robust and secure because the operation is completed (relatively) quickly. Ans C doesn't really fly.
Comment: Select answer: B Why? The essence of the S3 File Gateway is to provide a seamless interface for on-premises apps to store and retrieve data in Amazon S3 using standard protocols such as NFS and SMB. On the other hand, As I write this, the first AWS Official use case for Snowball is to migrate data especially when network conditions are limited. The question is a bit tricky. But applying simple logical linguistic analysis, "as soon as possible" coupled with "the least network bandwidth possible" means the question's focal point is network bandwidth. So, whatever the least network bandwidth is, it`s corresponding time to get the data into AWS S3 bucket is the value for "as soon as possible".
Comment: Snowball transfers data faster than the internet, and in this case, as the size of the data is large, so this would be the best option
Comment: Question specifically mentions minimal use of Network bandwidth. Storage gateway are mostly for using cloud storage on-premises. Usually data is copied one time using DataSync or other services like Snow devices.
Comment: Minimising network bandwidth
Comment: B for sure
Comment: Through Snowball edge, large amount of data can be transferred to AWS faster and securely.
Comment: B is the only solution which satisfies the bandwidth requirement.
Comment: B seems to be the correct answer
Comment: A would be way too long + bandwidth usage C would use bandwidth D would take several weeks For me, B is the lesser evil
Comment: 1. point to use least possible network bandwidth where snowball is a physical device so no use of internet. 2. The data is in TB not GB, so better to use snowball
Comment: D makes more sense to me.
Comment: By default, an SQS queue can handle a maximum of 3,000 messages per second. However, you can request higher throughput by contacting AWS Support. AWS can increase the message throughput for your queue beyond the default limits in increments of 300 messages per second, up to a maximum of 10,000 messages per second. It's important to note that the maximum number of messages per second that a queue can handle is not the same as the maximum number of requests per second that the SQS API can handle. The SQS API is designed to handle a high volume of requests per second, so it can be used to send messages to your queue at a rate that exceeds the maximum message throughput of the queue.
Comment: of course, the answer is D
Comment: D. Publish the messages to an Amazon Simple Notification Service (Amazon SNS) topic with multiple Amazon Simple Queue Service (Amazon SQS) subscriptions. Configure the consumer applications to process the messages from the queues. This solution uses Amazon SNS and SQS to publish and subscribe to messages respectively, which decouples the system and enables scalability by allowing multiple consumer applications to process the messages in parallel. Additionally, using Amazon SQS with multiple subscriptions can provide increased resiliency by allowing multiple copies of the same message to be processed in parallel.
Comment: Keywords: - The number of messages varies drastically - Sometimes increases suddenly to 100,000 each second A: Incorrect - Don't confuse between Kinesis Data Analytics and Kinesis Data Stream =)) Kinesis Data Analytics will get the data from Kinesis Data Stream or Kinesis Data FireHose or MSK (Managed Stream for apache Kafka) for analytic purpose. It can not consume message and send to applications. B: Incorrect - Base on the keywords -> Auto Scaling group not scale well because it need time to check the CPU metric and need time to start up the EC2 and the messages varies drastically. Example: we have to scale from 10 to 100 EC2. Our servers may be down a while when it was scaling. C: Incorrect - Kinesis Data Streams can handle this case but we should increase the more shards but not single shard. D: Correct: We can handle high workload well with fan-out pattern SNS + multiple SQS -> This is good for use case: - The number of messages varies drastically - Sometimes increases suddenly to 100,000 each second
Comment: oh... I confused between Kinesis Data Analytics and Kinesis Data Stream as you mentioned... I solved several this type of questions, but SNS is always about 'notification', so i choose A. but i think Kinesis Data Analytics is just wrong, so D is most correct answer.
Comment: ***CORRECT ANSWER*** The correct solution that meets these requirements is Option D: Publish the messages to an Amazon Simple Notification Service (Amazon SNS) topic with multiple Amazon Simple Queue Service (Amazon SQS) subscriptions. Configure the consumer applications to process the messages from the queues. Option D involves using Amazon Simple Notification Service (SNS) and Amazon Simple Queue Service (SQS) to decouple the solution and increase scalability. SNS is a fully managed, publish-subscribe messaging service that allows you to send messages to multiple recipients simultaneously. SQS is a fully managed, distributed message queue service that enables you to store, process, and transmit messages between microservices, distributed systems, and serverless applications.
Comment: To implement this solution, you would first publish the incoming messages to an SNS topic. You could then create multiple SQS subscriptions to the SNS topic, and configure the consumer applications to process the messages from the queues. This approach allows you to decouple the ingestion application from the consumer applications, and it allows you to scale the number of consumer applications independently of the ingestion application.
Comment: ***WRONG AS EXPLAINED*** Option A involves persisting the messages to Amazon Kinesis Data Analytics and configuring the consumer applications to read and process the messages. This option would not be the most efficient solution, as it would require the consumer applications to continuously poll Kinesis Data Analytics for new messages, which could impact their performance. Option B involves deploying the ingestion application on Amazon EC2 instances in an Auto Scaling group to scale the number of EC2 instances based on CPU metrics. This option would not decouple the solution and increase scalability, as the consumer applications would still be directly connected to the ingestion application.
Comment: Option C involves writing the messages to Amazon Kinesis Data Streams with a single shard and using an AWS Lambda function to preprocess the messages and store them in DynamoDB. This option would not be the most efficient solution, as it would require the consumer applications to continuously poll DynamoDB for new messages, which could impact their performance. Overall, Option D is the most effective solution for decoupling the solution and increasing scalability.
Comment: SNS and SQS still have an standard limit of tails under 3000 messages per sec, because SNS and SQS still have an standard limit of tails under 3000 messages per sec. It does not accomplishes with the requirement. Perharps it's a possible solution: Amazon Kinesis Data Analytics. Configure the consumer applications to read and process the messages, but it requires that change the arch of this app, but this point is no matter on ther requirement.
Comment: thats for FIFO queue.
Comment: for standard queue there is nearly no limit to messages
Comment: Option A: It is more suitable for real-time analytics and processing of streaming data rather than decoupling and scaling message ingestion and consumption. Option B: It may help with scalability to some extent, but it doesn't provide decoupling. Option C: It is a valid option, but it lacks the decoupling aspect. In this approach, the consumer applications would still need to read directly from DynamoDB, creating tight coupling between the ingestion and consumption processes. Option D: It is the recommended solution for decoupling and scalability. The ingestion application can publish messages to an SNS topic, and multiple consumer apps can subscribe to the relevant SQS queues. SNS ensures that each message is delivered to all subscribed queues, allowing the consuming apps to independently process the messages at their own pace and scale horizontally as needed. This provides loose coupling, scalability, and fault tolerance, as the queues can handle message spikes and manage the consumption rate based on the consumer's processing capabilities.
Comment: The answer is D. Publish the messages to an Amazon Simple Notification Service (Amazon SNS) topic with multiple Amazon Simple Queue Service (Amazon SQS) subscriptions. Configure the consumer applications to process the messages from the queues. This solution is the most scalable and decoupled solution for the given scenario. Amazon SNS is a pub/sub messaging service that can be used to decouple applications. Amazon SQS is a fully managed message queuing service that can be used to store and process messages. The solution would work as follows: The ingestion application would publish the messages to an Amazon SNS topic. The Amazon SNS topic would have multiple Amazon SQS subscriptions. The consumer applications would subscribe to the Amazon SQS queues. The consumer applications would process the messages from the Amazon SQS queues.
Comment: D. is the answer. The question states that there are dozens of other applications and microservices that consume these messages and that the volume of messages can vary drastically and increase suddenly. Therefore, you need a solution that can handle a high volume of messages, distribute them to multiple consumers, and scale quickly. SNS with SQS provides these capabilities. Publishing messages to an SNS topic with multiple SQS subscriptions is a common AWS pattern for achieving both decoupling and scalability in message-driven systems. SNS allows messages to be fanned out to multiple subscribers, which in this case would be SQS queues. Each consumer application could then process messages from its SQS queue at its own pace, providing scalability and ensuring that all messages are processed by all consumer applications. A. Amazon Kinesis Data Analytics is primarily used for real-time analysis of streaming data. It's not designed to distribute messages to multiple consumers.
Comment: Option D Amazon SNS allows you to publish messages to a topic, which can then fan out those messages to multiple subscribers. By using Amazon SQS as a subscriber to the SNS topic, you can handle the message load in a decoupled and scalable way. SQS can store messages until the consuming application is ready to process them, helping to smooth out the variance in message load. This approach allows the company to effectively decouple the message producing applications from the consuming applications, and it can easily scale to handle the high load of messages. The number of messages (100,000 each second) might require careful configuration and sharding of SQS queues or use of FIFO queues to ensure that they can handle the load. Options A, B, and C have their own limitations:
Comment: D. Here's why option D is the correct choice: Amazon SNS: Amazon SNS is a fully managed pub/sub messaging service that enables message publishing and subscription to topics. It provides fast and flexible communication between publishers and subscribers. Amazon SQS: Amazon SQS is a fully managed message queuing service that decouples the components of a distributed application. It offers reliable and scalable queues for storing messages and enables applications to process them asynchronously. By publishing the messages to an Amazon SNS topic and using Amazon SQS subscriptions, the solution achieves decoupling and scalability. Multiple applications and microservices can subscribe to the topic and receive messages through their individual SQS queues. This allows for parallel processing and enables the system to handle varying message volumes, including spikes of up to 100,000 messages per second.
Comment: D. Here's why option D is the correct choice: Amazon SNS: Amazon SNS is a fully managed pub/sub messaging service that enables message publishing and subscription to topics. It provides fast and flexible communication between publishers and subscribers. Amazon SQS: Amazon SQS is a fully managed message queuing service that decouples the components of a distributed application. It offers reliable and scalable queues for storing messages and enables applications to process them asynchronously. By publishing the messages to an Amazon SNS topic and using Amazon SQS subscriptions, the solution achieves decoupling and scalability. Multiple applications and microservices can subscribe to the topic and receive messages through their individual SQS queues. This allows for parallel processing and enables the system to handle varying message volumes, including spikes of up to 100,000 messages per second.
Comment: Ans A. Solution requires decoupling. SNS is FIFO. Also (hinted at): messages are forwarded to other services so need some level of processing
Comment: SNS can handle the high throughput of up to 100,000 messages per second. Amazon Kinesis typical use cases are 1.Real-Time Dashboards 2.Streaming ETL (Extract, Transform, Load) 3.Log and Event Monitoring 4. IoT Analytics 5. Clickstream Analysis
Comment: D is accurate answer
Comment: SNS decouple the order and secure the message during transferring
Comment: D for sure
Comment: Answer is A because you have to decouple the solution. Anything ecoupling has to do with kinesis
Comment: Using Amazon SNS and SQS together provides a scalable, decoupled architecture that can handle high message throughput and variable load efficiently, making it the best fit for the requirements.
Comment: A - incorrect: Schedule scaling policy doesn't make sense. C, D - incorrect: Primary server should not be in same Auto Scaling group with compute nodes. B is correct.
Comment: The answer seems to be B for me: A: doesn't make sense to schedule auto-scaling C: Not sure how CloudTrail would be helpful in this case, at all. D: EventBridge is not really used for this purpose, wouldn't be very reliable
Comment: keywords: - Legacy platform consists of a primary server that coordinates jobs across multiple compute nodes. - Maximizes resiliency and scalability. A: Incorrect - the question don't mention about schedule for high workload. So we don't use scheduled scaling for this case. B: Correct - SQS can keep your message in the queue in case of high workload and if it too high we can increase the EC2 instance base on size of the queue. C: Incorrect - AWS CloudTrail is API logs it is use for audit log of AWS user activity. D: Incorrect - Event Bridge is use for filter event and trigger event.
Comment: B. Explanation: To maximize resiliency and scalability, the best solution is to use an Amazon SQS queue as a destination for the jobs. This decouples the primary server from the compute nodes, allowing them to scale independently. This also helps to prevent job loss in the event of a failure. Using an Auto Scaling group of Amazon EC2 instances for the compute nodes allows for automatic scaling based on the workload. In this case, it's recommended to configure the Auto Scaling group based on the size of the Amazon SQS queue, which is a better indicator of the actual workload than the load on the primary server or compute nodes. This approach ensures that the application can handle variable workloads, while also minimizing costs by automatically scaling up or down the compute nodes as needed.
Comment: SQS helps to process messages in case of variable workloads. The compute nodes must be implemented using EC2 instances (or alternatively, ECS tasks or managed Kubernetes nodes, but this option is not available). AutoScaling must be based on the workload, which is controlled by the queue. So, the correct option is B. A is not correct because the instances should not scale based on a schedule which is not deterministic. On the contrary, scales based on the workload (queue size) is more effective. AWS CloudTrail should not be used as a destination job and it is not related to the question. The same applies to EventBridge.
Comment: B: Explanation: Amazon SQS provides a reliable, highly scalable, and fully managed message queuing service that enables you to decouple and coordinate the components of a distributed application. EC2 Auto Scaling allows you to automatically adjust the number of EC2 instances based on demand, ensuring that your application can handle variable workloads efficiently. Auto Scaling based on the size of the queue ensures that your application scales out when there are many jobs to process and scales in when the job load decreases, providing cost efficiency and responsiveness to workload changes.
Comment: According to them , Option C is correct how?
Comment: A lot of answer B's... but I'm not convinced its Ans B which states: “Configure EC2 Auto Scaling based on the size of the queue” – because basing scaling on the size of the queue ignores the specific workload each job requires. The problem states “The application serves variable workloads” – you can't determine the processing required for a variable workload based solely on queue size; this can only be done when you scope the size of the specific variable load – and that to my mind points to answer D: “Configure EC2 Auto Scaling based on the load on the compute nodes” – but then I run into the (potential) problem that Eventbridge may not be up to the task…
Comment: why are almost all of the "correct answers" I see on this site all wrong? how the fuck is this an educational resource? good thing the community voting system exists or else this side would be pure unadulterated putrid shit.
Comment: B for sure
Comment: B for sure
Comment: option D leverages serverless services (EventBridge) and Auto Scaling for a modern, scalable, and resilient architecture suitable for the distributed application with varying workloads.
Comment: In option C, Ignore the line that's talking about cloud trail and then the answer would make much more sense.
Comment: B for sure
Comment: B is correct because we need auto scaling, and a value to scaling
Comment: Correct option B. SQS is used to decouple the distributed architecture (primary server and compute nodes). Scheduled auto scaling doesn't make sense as the workload is variable, so based on size of the queue is the correct option.
Comment: the correct solution is B, because in the requirement is said "the application serves variable workloads" and we need to decouple monolithic infrastructure here so this required SQS.
Comment: This option leverages Amazon SQS to decouple the primary server from the compute nodes, ensuring resiliency and scalability. The compute nodes can be managed in an Auto Scaling group, scaling based on the size of the SQS queue, which reflects the workload. This design allows the system to handle variable workloads efficiently while maximizing scalability and resiliency.
Comment: Answer directly points towards file gateway with lifecycles, D is wrong because utility function is vague and there is no need for flexible storage.
Comment: I think B is wrong because they are not asking you to add more room, they are asking you to have more room available.
Comment: Yes it might be vague but how do we keep the low-latency access that only flexible can offer?
Comment: Low-latency access is only required for the first 7 days, B maintains that fast access for 7 days and only then are the files sent to Glacier Archive
Comment: It says low-latency is required for the most recently accessed files, not new ones. So if an older file is retrieved from deep archive, it should then readily be accessible, according to the question, which points toward Flexible retrieval. However the utility portion in the answer D is vague.
Comment: file gateway comes with a cache volume on-premise wich ensures the low latency for the most recently accessed files
Comment: B answwer is correct. low latency is only needed for newer files. Additionally, File GW provides low latency access by caching frequently accessed files locally so answer is B
Comment: B is correct
Comment: The same question and answer explanation exists in a Udemy course. Correct answer is B. Amazon S3 File Gateway provides a seamless way to connect to the cloud to store application data files and backup images as durable objects in Amazon S3 cloud storage. Amazon S3 File Gateway offers SMB or NFS-based access to data in Amazon S3 with local caching. It can be used for on-premises data-intensive Amazon EC2-based applications that need file protocol access to S3 object storage. Lifecycle policies can then transition the data to S3 Glacier Deep Archive after 7 days. D is wrong because is involves too much extra configuration which is unnecessary.
Comment: Option B, creating an Amazon S3 File Gateway and an S3 Lifecycle policy to transition data to S3 Glacier Deep Archive, would meet the requirements specified in the prompt. The S3 File Gateway allows you to store and retrieve objects in Amazon S3 using standard file system protocols, such as SMB and NFS. This would provide additional storage space for the company's data and allow for low-latency access to the most recently accessed files, as the data would still be stored on the SMB file server.
Comment: Option A, using AWS DataSync to copy data that is older than 7 days from the SMB file server to AWS, would not provide additional storage space for the company's data and would not allow for low-latency access to the most recently accessed files. Option C, creating an FSx for Windows File Server file system, would provide additional storage space but would not include file lifecycle management. Option D, installing a utility on each user's computer to access Amazon S3 and creating an S3 Lifecycle policy, would not provide additional storage space on the company's file server.
Comment: Explanation: Since the company needs to increase available storage space while maintaining low-latency access to recently accessed files and implement file lifecycle management to avoid future storage issues, the best solution is to use Amazon S3 with a File Gateway. Using an Amazon S3 File Gateway, the company can access its SMB file server through an S3 bucket. This provides low-latency access to recently accessed files by caching them on the gateway appliance. The solution also supports file lifecycle management by using S3 Lifecycle policies to transition files to lower cost storage classes after they haven't been accessed for a certain period of time. In this case, the company can create an S3 Lifecycle policy to transition files to S3 Glacier Deep Archive after 7 days of not being accessed. This would allow the company to store large amounts of data at a lower cost, while still having easy access to recently accessed files.
Comment: Keywords: - After 7 days the files are rarely accessed. -The total data size is increasing and is close to the company's total storage capacity. - Increase the company's available storage space without losing low-latency access to the most recently accessed files. -> (for rarely accessed files we can access it with high-latency) - Must also provide file lifecycle management to avoid future storage issues. A: Incorrect - Don't mention how to increase company's available storage space. B: Correct - extend storage space and fast access with S3 File Gateway (cache recent access file), reduce cost and storage by move to S3 Glacier Deep Archive after 7 days. C: Incorrect - Didn't handle file lifecycle management. D: Incorrect - Don't mention about increase the company's available storage space.
Comment: according to documentation the minimum storage timeframe for an object inside S3 before being able to transition using lifecycle policy is 30 days , so those 7 days policies kinda seem wrong to me Transition actions – These actions define when objects transition to another storage class. For example, you might choose to transition objects to the S3 Standard-IA storage class 30 days after creating them, or archive objects to the S3 Glacier Flexible Retrieval storage class one year after creating them. For more information, see Using Amazon S3 storage classes. I was thinking of option A using DataSync as a scheduled task? am i wrong here?
Comment: A. DataSync is focused on transferring data when we need synchronization (for example, from an on-premises DB that updates daily to a DB in AWS). In this case, we don't need to transfer data or synchronize data, we only need to increase the storage. So, this option is not correct. B. S3 File Gateway allows communication between a File System/Server and S3, and it supports SMB protocol. We can use S3 FGW to move files from the FS to the S3 bucket. Then, the question says that files older than seven days are rarely accessed, so we can transition to S3 Glacier for those files to archive, in a costly-efficient way. So, this option is correct. C. You have two different storages for saving the files, making the interoperability unnecessarily more complex (and you need constant data synchronization, regarding to option A). D. This is a mess. The solution is not scalable and It depends on the number of users, which is not a static number. Additionally, Flexible Retrieval is unnecessary.
Comment: answwer is correct. low latency is only needed for newer files. Additionally, File GW provides low latency access by caching frequently accessed files locally so answer is B
Comment: B is correct
Comment: Ans B: Low latency is only required for recent files in last 7 days; the rest can effectively be archived.
Comment: I'm new to this site, B is obviously correct, so how can D be shown as the "Correct Answer"? Makes no sense..
Comment: B: Explanation: Amazon S3 File Gateway: This service provides a seamless and secure integration between on-premises environments and the Amazon S3 cloud storage, allowing users to store and retrieve objects in S3 using the standard file protocols. S3 Lifecycle policy: By creating a lifecycle policy, you can automatically transition data that is older than 7 days to a more cost-effective storage class like S3 Glacier Deep Archive, which is suitable for infrequently accessed data.
Comment: Best answer opt C
Comment: File gateway has a cache and when hybrid is needed always think a storage gateway solution
Comment: Option B: Use an Amazon S3 File Gateway to extend storage space and create an S3 Lifecycle policy to transition data to S3 Glacier Deep Archive after 7 days. This solution provides seamless storage expansion, low-latency access for recent files, and cost-effective lifecycle management for older data.
Comment: B because FIFO is made for that specific purpose
Comment: Should be B because SQS FIFO queue guarantees message order.
Comment: Standard queues ensure at-least-once message delivery, but due to the highly distributed architecture, more than one copy of a message might be delivered, and messages may occasionally arrive out of order.
Comment: AnswerB - SQS FIFO queues ensure that messages are processed in the order they are received, which perfectly matches the requirement of maintaining order.
Comment: A lot of answers seem to not match the most voted. i'm confused which to follow.
Comment: Explanation: To ensure that orders are processed in the order that they are received, the best solution is to use an Amazon SQS FIFO (First-In-First-Out) queue. This type of queue maintains the exact order in which messages are sent and received. In this case, the application can send information about new orders to an Amazon API Gateway REST API, which can then use an API Gateway integration to send a message to an Amazon SQS FIFO queue for processing. The queue can then be configured to invoke an AWS Lambda function to perform the necessary processing on each order. This ensures that orders are processed in the exact order in which they are received.
Comment: Keywords: - Orders are processed in the order that they are received. A: Incorrect - SNS just for notification like send email, SMS. It don't retain the data in the queue and it's used pub-sub pattern. B: Correct - SQS FIFO will help message process in order. FIFO -> first in first out. C: Incorrect - with this solution we will create blocker app not good app =)) D: Incorrect - SQS standard don't guarantee the order.
Comment: Explanation: - Amazon API Gateway will be used to receive the orders from the web application. - Instead of directly processing the orders, the API Gateway will integrate with an Amazon SQS FIFO queue. - FIFO (First-In-First-Out) queues in Amazon SQS ensure that messages are processed in the order they are received. - By using a FIFO queue, the order processing is guaranteed to be sequential, ensuring that the first order received is processed before the next one. - An AWS Lambda function can be configured to be triggered by the SQS FIFO queue, processing the orders as they arrive
Comment: A. This option could be correct if we use SNS FIFO option, but this is not the case stated in the question. Additionally, this task is more efficient done by a queue than a subscription service. So, this option is not correct. B. We use a queue, which is efficient processing messages. Additionally, it preserves the order since it is a FIFO queue. Meanwhile we don't have any kind of messages throughput limitation, this option is correct. C. This option discards any messages that are still processing, which is not a good solution. D. Same option as B but using a normal queue, which does not preserve the order. Incorrect.
Comment: FIFO is crucial to ensuring the solution works. Two answers use SQS and the author has differentiated between these option by specifically stating in option B “FIFO” On the other hand, SNS also has a FIFO option but the author has chosen to not state that in answer A. If the author had said in option A: “…with FIFO” then A could have been a viable answer. Therefore it has to be Ans B (not A as the author recommends).
Comment: FIFO is crucial to ensuring the solution works. Two answers (B & D) use SQS and the author has differentiated between these by specifically stating in answer B “FIFO”. On the other hand (answer A), SNS also has a FIFO option but the author has chosen to not state that in answer A. If the author had been consistent and said in answer A: “…with FIFO” then A could have been a viable answer. Therefore it has to be Ans B (not A as the author recommends).
Comment: FIFO ensures message order
Comment: B. SQS FIFO as order of processing should be same as order of receiving
Comment: Use an Amazon SQS FIFO (First-In-First-Out) Queue to ensure that orders are processed in the exact order they are received. The FIFO queue guarantees message order and exactly-once processing.
Comment: B for sure
Comment: what's up with all these strange answers!!!! I chose B, SQS FIFO is designed for this exact use case, why does the author claim that A is the correct answer??
Comment: B seems to be the answer
Comment: B is wrong because parameter store does not support auto rotation, unless the customer writes it themselves, A is the answer.
Comment: READ!!! AWS Secrets Manager is a secrets management service that helps you protect access to your applications, services, and IT resources. This service enables you to rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.
Comment: A - additionally, Aurora manages the settings for the secret and rotates the secret every seven days by default.
Comment: ty bro, I was confused about that and you just mentioned the "key" phrase, B doesn't support autorotation
Comment: Option A: Using AWS Secrets Manager and enabling automatic rotation is the recommended solution for minimizing the operational overhead of credential management. AWS Secrets Manager provides a secure and centralized service for storing and managing secrets, such as database credentials. By leveraging Secrets Manager, the application can retrieve the database credentials programmatically at runtime, eliminating the need to store them locally in a file. Enabling automatic rotation ensures that the database credentials are regularly rotated without manual intervention, enhancing security and compliance.
Comment: This is an ideal solution. Secrets Manager can rotate credentials automatically and ensures that the EC2 instances retrieve the most recent credentials securely.
Comment: Option A, using AWS Secrets Manager and turning on automatic rotation, would be the best solution to minimize the operational overhead of credential management. AWS Secrets Manager is a service that makes it easier to manage secrets, such as database credentials, by storing and rotating them automatically. By turning on automatic rotation, you can ensure that the secrets are regularly rotated, reducing the risk of unauthorized access to the database. This would minimize the operational overhead of credential management, as you would not have to manually rotate the secrets or update the EC2 instances with the new credentials.
Comment: Option B, using AWS Systems Manager Parameter Store and turning on automatic rotation, would not be suitable for storing secrets, such as database credentials, as it is intended for storing system parameters. Option C, creating an S3 bucket to store objects that are encrypted with an AWS KMS encryption key and migrating the credential file to the S3 bucket, would not provide automatic rotation of the secrets. Option D, creating an encrypted EBS volume and migrating the credential file to the new EBS volume, would not provide automatic rotation of the secrets.
Comment: A: READ!!! AWS Secrets Manager is a secrets management service that helps you protect access to your applications, services, and IT resources. This service enables you to rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. It says SSM Parameter store cant rotate automatically.
Comment: Everybody here voting A, but only the master user's password of the Aurora database can be automatically stored and rotated. Who uses the master user's credentials in their application ? It looks to me like a serious security issue... Moreover answer A is not complete, missing steps are: - create IAM role to get secret - assign IAM role to EC2 instance - adapt the application to retrieve the secret from Secrets Manager instead of erading the file - make sure retrieval occurs every week I dont' call that minimizing operational overhead... Answer D is a lot more simple. In a real situation, none of these answers are relevant.
Comment: Same thing I thought. Answer D seems simpler, but option A is the best approach.
Comment: Option A , because of leas overhead.
Comment: Parameter Store: Storing and managing a database connection string or API endpoint URL that doesn't require frequent rotation. Secrets Manager: Storing and managing database credentials that need to be rotated regularly for security compliance.
Comment: Answer A is correct
Comment: Secrets Manager, as The Mandalorian would say "this is the way!"
Comment: SSM has no automatic rotation.
Comment: The most suitable option for minimizing operational overhead of credential management in this scenario is: B. Use AWS Systems Manager Parameter Store. Turn on automatic rotation. AWS Systems Manager Parameter Store is a service that helps you manage configuration data, including sensitive information such as passwords and database strings, in a central, secure store. With automatic rotation enabled, the credentials can be automatically updated at scheduled intervals, reducing the manual effort required for credential management.
Comment: Secret manager with auto rotation.
Comment: BCD are extremely high operational overhead and not secure like A
Comment: A is correct
Comment: B becasue the user wants reduce costs and SSM Parameter Store layer Standard is free and the type SecureString uses KMS
Comment: It should be "A."
Comment: Answer is A Explanation - AWS Global Accelerator vs CloudFront • They both use the AWS global network and its edge locations around the world • Both services integrate with AWS Shield for DDoS protection. • CloudFront • Improves performance for both cacheable content (such as images and videos) • Dynamic content (such as API acceleration and dynamic site delivery) • Content is served at the edge • Global Accelerator • Improves performance for a wide range of applications over TCP or UDP • Proxying packets at the edge to applications running in one or more AWS Regions. • Good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP • Good for HTTP use cases that require static IP addresses • Good for HTTP use cases that required deterministic, fast regional failover
Comment: A, adding to the excellent explanation by Kartikey140, the solution under C uses a custom DNS name, the question specifies: "The company is using its own domain name registered with Amazon Route 53"
Comment: By creating a CloudFront distribution that has both the S3 bucket and the ALB as origins, the company can reduce latency for both the static and dynamic data. The CloudFront distribution acts as a content delivery network (CDN), caching the data closer to the users and reducing the latency. The company can then configure Route 53 to route traffic to the CloudFront distribution, providing improved performance for the web application.
Comment: Q: How is AWS Global Accelerator different from Amazon CloudFront? A: AWS Global Accelerator and Amazon CloudFront are separate services that use the AWS global network and its edge locations around the world. CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery). Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions. Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover. Both services integrate with AWS Shield for DDoS protection.
Comment: Keywords: - The web application has static data and dynamic data. Static data in an Amazon S3 bucket. - Improve performance and reduce latency for the static data and dynamic data. - The company is using its own domain name registered with Amazon Route 53. A: Correct - CloudFront has the Edge location and the cache for dynamic and static B: Incorrect - AWS Global Accelerator don't have cache function, so static file need to be load directly from S3 every time. - Beside that we configure CloudFront -> ALB, Accelerator -> S3, Route 53 -> CloudFront. It means that all the traffic go to CloudFront only, Acclerator don't have any traffic. C: Incorrect - Global Accelerator can configure CloudFront as the endpoint. D: Incorrect - We already have domain name. Why will we use new domain name? Will we change to new domain name? How everyone know you new domain name?
Comment: A. Create an Amazon CloudFront distribution that has the S3 bucket and the ALB as origins. Configure Route 53 to route traffic to the CloudFront distribution. Here's the reasoning: CloudFront with Multiple Origins: CloudFront allows you to set up multiple origins for your distribution, so you can use both the ALB (for dynamic content) and the S3 bucket (for static content) as origins. This means that both your dynamic and static content can be served through CloudFront, which will cache content at edge locations to reduce latency. Route 53 Integration with CloudFront: Amazon Route 53 can be easily configured to route traffic for your domain to a CloudFront distribution. Users will access your domain, and Route 53 will direct them to the nearest CloudFront edge location.
Comment: A is correct, other answers have wrong origin or endpoint types. Cloudfront supports multiple origins on the same distribution (ALB and S3) in our case. B incorrect - Global Accelerator Standard accelerator doesn;t support s3 endpoints c incorrect - Global Accelerator Standard accelerator doesn't support CloudFront distribution as endpoint D incorrect - Global Accelerator Standard accelerator doesn't support s3 endpoints
Comment: I'm wavering between A and C. With dynamic content, CloudFront is cacheable and that's not good. But with answer C, AWS Global doesn't support Cloudfront endpoint "Endpoints for standard accelerators in AWS Global Accelerator can be Network Load Balancers, Application Load Balancers, Amazon EC2 instances, or Elastic IP addresses. " So I choose A
Comment: Ans C - for the good reasons given by Diddy99. Altho' Ans A could do it, it is not the best optimised answer; Ans C is, but at cost of a custom domain name (which I don't like)
Comment: Cloudfront caches content at edge locations, reduces latency, and can serve static content from S3 buckets. It can also accelerate dynamic content from EC2. CloudFront maintains a persistent pool of connections to the origin, which minimises the overhead of establishing new connections. Any of these questions with "latency" and "improve performance" smell like CloudFront.
Comment: A - CloudFront for caching static content. No need for Global Accelerator since no static IP is required
Comment: A
Comment: A, adding to the excellent explanation by Kartikey140, the solution under C uses a custom DNS name, the question specifies: "The company is using its own domain name registered with Amazon Route 53"
Comment: Answer is C Explanation: A: Using Cloudfront to cache static content is perfect for low latency and performance. However, caching dynamic content from ALB through cloudfront might not be efficient as dynamic contents is often personalized and are not good for caching. B: Using cloudfront to cache dynamic contents from ALB is not the most efficient approach C: Using amazon cloudfront to cache the static data from S3 ensures efficient distribution of static contents globally. AWS Global accelerator routes traffic to the nearest AWS EDGE location. Hence, routing is optimized to both the ALB (Dynamic contents) and Cloud front distribution.
Comment: A for sure
Comment: By using CloudFront with separate origins for static and dynamic content, the company can achieve improved performance and reduced latency for both types of data. Route 53 then intelligently routes traffic based on the requested object, ensuring a smooth user experience.
Comment: It would have made sense to use S3 bucket as the origin for cloud front and ALB as the end point for global accelerator. However the option C messes it up when it mentions also the cloud front distribution as the end point for global accelerator standard (which is not supported). As this is not possible the only option left is A to use Cloud front for both S3 & ALB.
Comment: CloudFront can be used for both static and dynamic content distribution.
Comment: Answer is A
Comment: A is correct.
Comment: Keywords: - rotate the credentials for its Amazon RDS for MySQL databases across multiple AWS Regions - LEAST operational overhead A: Correct - AWS Secrets Manager supports - Encrypt credential for RDS, DocumentDb, Redshift, other DBs and key/value secret. - multi-region replication. - Remote base on schedule B: Incorrect - Secure string parameter only apply for Parameter Store. All the data in AWS Secrets Manager is encrypted C: Incorrect - don't mention about replicate S3 across region. D: Incorrect - So many steps compare to answer A =))
Comment: AWS Secrets Manager is a secrets management service that enables you to store, manage, and rotate secrets such as database credentials, API keys, and SSH keys. Secrets Manager can help you minimize the operational overhead of rotating credentials for your Amazon RDS for MySQL databases across multiple Regions. With Secrets Manager, you can store the credentials as secrets and use multi-Region secret replication to replicate the secrets to the required Regions. You can then configure Secrets Manager to rotate the secrets on a schedule so that the credentials are rotated automatically without the need for manual intervention. This can help reduce the risk of secrets being compromised and minimize the operational overhead of credential management.
Comment: Option A, storing the credentials as secrets in AWS Secrets Manager and using multi-Region secret replication for the required Regions, and configuring Secrets Manager to rotate the secrets on a schedule, would meet the requirements with the least operational overhead. AWS Secrets Manager allows you to store, manage, and rotate secrets, such as database credentials, across multiple AWS Regions. By enabling multi-Region secret replication, you can replicate the secrets across the required Regions to allow for seamless rotation of the credentials during maintenance activities. Additionally, Secrets Manager provides automatic rotation of secrets on a schedule, which would minimize the operational overhead of rotating the credentials on a monthly basis.
Comment: Option B, storing the credentials as secrets in AWS Systems Manager and using multi-Region secret replication, would not provide automatic rotation of secrets on a schedule. Option C, storing the credentials in an S3 bucket with SSE enabled and using EventBridge to invoke an AWS Lambda function to rotate the credentials, would not provide automatic rotation of secrets on a schedule. Option D, encrypting the credentials as secrets using KMS multi-Region customer managed keys and storing the secrets in a DynamoDB global table, would not provide automatic rotation of secrets on a schedule and would require additional operational overhead to retrieve the secrets from DynamoDB and use the RDS API to rotate the secrets.
Comment: With Secrets Manager, you can store, retrieve, manage, and rotate your secrets, including database credentials, API keys, and other secrets. When you create a secret using Secrets Manager, it's created and managed in a Region of your choosing. Although scoping secrets to a Region is a security best practice, there are scenarios such as disaster recovery and cross-Regional redundancy that require replication of secrets across Regions. Secrets Manager now makes it possible for you to easily replicate your secrets to one or more Regions to support these scenarios.
Comment: A. Store the credentials as secrets in AWS Secrets Manager. Use multi-Region secret replication for the required Regions. Configure Secrets Manager to rotate the secrets on a schedule. This solution is the best option for meeting the requirements with the least operational overhead. AWS Secrets Manager is designed specifically for managing and rotating secrets like database credentials. Using multi-Region secret replication, you can easily replicate the secrets across the required AWS Regions. Additionally, Secrets Manager allows you to configure automatic secret rotation on a schedule, further reducing the operational overhead.
Comment: Ans A. What's to debate...?
Comment: A - Secrets Manager automates the rotation of secrets for RDS without own implementation required, the options require effort to implement the secret rotation logic
Comment: A is correct.
Comment: Answer-A
Comment: Clearly A is the correct one.
Comment: 'The company needs to rotate the credentials for its Amazon RDS for MySQL databases across multiple AWS Regions' = AWS Secrets Manager
Comment: Option A MET THE REQUIREMENT
Comment: Option A: Storing the credentials as secrets in AWS Secrets Manager provides a dedicated service for secure and centralized management of secrets. By using multi-Region secret replication, the company ensures that the secrets are available in the required Regions for rotation. Secrets Manager also provides built-in functionality to rotate secrets automatically on a defined schedule, reducing operational overhead. This automation simplifies the process of rotating credentials for the Amazon RDS for MySQL databases during monthly maintenance activities.
Comment: A is correct answer.
Comment: A is correct.
Comment: A
Comment: C, AURORA is 5x performance improvement over MySQL on RDS and handles more read requests than write,; maintaining high availability = Multi-AZ deployment
Comment: Option C, using Amazon Aurora with a Multi-AZ deployment and configuring Aurora Auto Scaling with Aurora Replicas, would be the best solution to meet the requirements. Aurora is a fully managed, MySQL-compatible relational database that is designed for high performance and high availability. Aurora Multi-AZ deployments automatically maintain a synchronous standby replica in a different Availability Zone to provide high availability. Additionally, Aurora Auto Scaling allows you to automatically scale the number of Aurora Replicas in response to read workloads, allowing you to meet the demand of unpredictable read workloads while maintaining high availability. This would provide an automated solution for scaling the database to meet the demand of the application while maintaining high availability.
Comment: Option A, using Amazon Redshift with a single node for leader and compute functionality, would not provide high availability. Option B, using Amazon RDS with a Single-AZ deployment and configuring RDS to add reader instances in a different Availability Zone, would not provide high availability and would not automatically scale the number of reader instances in response to read workloads. Option D, using Amazon ElastiCache for Memcached with EC2 Spot Instances, would not provide a database solution and would not meet the requirements.
Comment: Ans C. Its the only one that offers right level of scaling and availability
Comment: Here's why C is the best solution: Amazon Aurora: A managed, high-performance MySQL-compatible relational database engine. Multi-AZ deployment: Ensures high availability in case of an AZ failure. Aurora Auto Scaling with Aurora Replicas: Automatically scales read replicas based on traffic, improving read performance.
Comment: Answer-c
Comment: key statement: "...will automatically scale the database to meet the demand of unpredictable read workloads while maintaining high availability.
Comment: Aurora
Comment: C fit perfectly
Comment: Unpredictable read workloads while maintaining high availability = Amazon Aurora with a Multi-AZ deployment, Auto Scaling with Aurora read replicas.
Comment: As the application handles more read requests than write transactions, using read replicas with Aurora is an ideal choice as it allows read scaling without sacrificing write performance on the primary instance.
Comment: Option C MET THE REQUIREMENT
Comment: Option C
Comment: Option C: Using Amazon Aurora with a Multi-AZ deployment and configuring Aurora Auto Scaling with Aurora Replicas is the most appropriate solution. Aurora is a MySQL-compatible relational database engine that provides high performance and scalability. With Multi-AZ deployment, the database is automatically replicated across multiple Availability Zones for high availability. Aurora Auto Scaling allows the database to automatically add or remove Aurora Replicas based on the workload, ensuring that read requests can be distributed effectively and the database can scale to meet demand. This provides both high availability and automatic scaling to handle unpredictable read workloads.
Comment: C meets the requirements.
Comment: C Aurora with read replicas
Comment: Key words: - Must support MySQL - High Availability (must be mulit-az) - Auto Scaling
Comment: C is correct since cost is not a concern.
Comment: I would recommend option C: Use AWS Network Firewall to create the required rules for traffic inspection and traffic filtering for the production VPC. AWS Network Firewall is a managed firewall service that provides filtering for both inbound and outbound network traffic. It allows you to create rules for traffic inspection and filtering, which can help protect your production VPC. Option A: Amazon GuardDuty is a threat detection service, not a traffic inspection or filtering service. Option B: Traffic Mirroring is a feature that allows you to replicate and send a copy of network traffic from a VPC to another VPC or on-premises location. It is not a service that performs traffic inspection or filtering. Option D: AWS Firewall Manager is a security management service that helps you to centrally configure and manage firewalls across your accounts. It is not a service that performs traffic inspection or filtering.
Comment: I agree with C. **AWS Network Firewall** is a stateful, managed network firewall and intrusion detection and prevention service for your virtual private cloud (VPC) that you created in Amazon Virtual Private Cloud (Amazon VPC). With Network Firewall, you can filter traffic at the perimeter of your VPC. This includes filtering traffic going to and coming from an internet gateway, NAT gateway, or over VPN or AWS Direct Connect.
Comment: And I'm not sure Traffic Mirroring can be for filtering
Comment: AWS Network Firewall is a managed network firewall service that allows you to define firewall rules to filter and inspect network traffic. You can create rules to define the traffic that should be allowed or blocked based on various criteria such as source/destination IP addresses, protocols, ports, and more. With AWS Network Firewall, you can implement traffic inspection and filtering capabilities within the production VPC, helping to protect the network traffic. In the context of the given scenario, AWS Network Firewall can be a suitable choice if the company wants to implement traffic inspection and filtering directly within the VPC without the need for traffic mirroring. It provides an additional layer of security by enforcing specific rules for traffic filtering, which can help protect the production environment.
Comment: - AWS Network Firewall is a managed network security service that provides stateful inspection of traffic and allows you to define firewall rules to control the traffic flow in and out of your VPC. - With AWS Network Firewall, you can create custom rule groups to define specific operations for traffic inspection and filtering. - It can perform deep packet inspection and filtering at the network level to enforce security policies, block malicious traffic, and allow or deny traffic based on defined rules. - By integrating AWS Network Firewall with the production VPC, you can achieve similar functionalities as the on-premises inspection server, performing traffic flow inspection and filtering.
Comment: Ans C. As per good response by SilentMili
Comment: I didn't realize the network firewall could do inspection, but here's what the documentation says: AWS Network Firewall supports Transport Layer Security (TLS) inspection, allowing customers to strengthen their security posture on AWS by improving visibility into encrypted traffic flows. You can use AWS Network Firewall to decrypt TLS sessions and inspect both inbound and outbound Amazon Virtual Private Cloud (VPC) traffic without the need to deploy or manage any additional network security infrastructure. Encryption and decryption happen on the same firewall instance natively, so traffic does not cross any network boundaries.
Comment: Network Firewall to define firewall rules for traffic inspection. A: GuardDuty is not for this B: Wrong product D: Firewall Manager does not monitor traffic, it manages firewall
Comment: Answer-C
Comment: AWS Nework Firewall to support from layert 3 to layer 7 protection, it is able to inspect any direction lets say vpc to vpc and outbound and inbound and even supporting direct connect and site to site vpn
Comment: AWS Network Firewall is a managed firewall service that provides filtering for both inbound and outbound network traffic. It allows you to create rules for traffic inspection and filtering, which can help protect your production VPC.
Comment: Why isn't D viable? Firewall Manager will help to provision network firewall as required if you define it in firewall manager. And it's fully managed, not requiring you to do any configuration or set up.
Comment: Because we need a firewall, not a service that we COULD IN THEORY use to create a firewall?
Comment: C with no doubt
Comment: Option C MET THE REQUIREMENT
Comment: B is correct answer
Comment: option B with Traffic Mirroring is the most suitable solution for mirroring the traffic from the production VPC to an inspection instance or tool, allowing you to perform traffic inspection and filtering as required.
Comment: C is correct as the option uses AWS services to fully meet the requirement. Has the question not been asking "in the AWS cloud", option B could be a correct option too, but a costlier one though as the user has to pay for network data for every bit of traffic replication between AWS cloud and on-prem location.
Comment: Option B is correct, no need to send traffic to on-prem, also the inspection server migrated to Cloud too.
Comment: Traffic Mirroring will allow you to inspect and filter traffic using a server, (note company had a on-premise server for Traffic filtering )
Comment: B
Comment: Agree with you
Comment: Keywords: - Data lake on AWS. - Consists of data in Amazon S3 and Amazon RDS for PostgreSQL. - The company needs a reporting solution that provides data VISUALIZATION and includes ALL the data sources within the data lake. A - Incorrect: Amazon QuickSight only support users(standard version) and groups (enterprise version). users and groups only exists without QuickSight. QuickSight don't support IAM. We use users and groups to view the QuickSight dashboard B - Correct: as explained in answer A and QuickSight is used to created dashboard from S3, RDS, Redshift, Aurora, Athena, OpenSearch, Timestream C - Incorrect: This way don't support visulization and don't mention how to process RDS data D - Incorrect: This way don't support visulization and don't mention how to combine data RDS and S3
Comment: If you have data in sources other than Amazon S3, you can use Athena Federated Query to query the data in place or build pipelines that extract data from multiple data sources and store them in Amazon S3. With Athena Federated Query, you can run SQL queries across data stored in relational, non-relational, object, and custom data sources. Athena uses data source connectors that run on AWS Lambda to run federated queries. A data source connector is a piece of code that can translate between your target data source and Athena. You can think of a connector as an extension of Athena's query engine. Prebuilt Athena data source connectors exist for data sources like Amazon CloudWatch Logs, Amazon DynamoDB, Amazon DocumentDB, and Amazon RDS, and JDBC-compliant relational data sources such MySQL, and PostgreSQL under the Apache 2.0 license
Comment: Option B is the correct answer because Amazon QuickSight's sharing mechanism is based on users and groups, not IAM roles. IAM roles are used for granting permissions to AWS resources, but they are not directly used for sharing QuickSight dashboards. In option B, you create an analysis in Amazon QuickSight, connect all the data sources (Amazon S3 and Amazon RDS for PostgreSQL), and create new datasets. After publishing dashboards to visualize the data, you share them with appropriate users and groups. This approach allows you to control the access levels for different users, such as providing full access to the management team and limited access to the rest of the company. This solution meets the requirements specified in the question.
Comment: Amazon QuickSight is a cloud-based business intelligence (BI) service that makes it easy to create and publish interactive dashboards that include data visualizations from multiple data sources. By using QuickSight, the company can connect to both Amazon S3 and Amazon RDS for PostgreSQL and create new datasets that combine data from both sources. The company can then use QuickSight to create interactive dashboards that visualize the data and provide data insights. To limit access to the visualizations, the company can use QuickSight's built-in security features. QuickSight allows you to define fine-grained access control at the user or group level. This way, the management team can have full access to all the visualizations, while the rest of the company can have only limited access.
Comment: tricky question, Users, groups and roles can have access. Viewing who has access to a dashboard Use the following procedure to see which users or groups have access to the dashboard. Open the published dashboard and choose Share at upper right. Then choose Share dashboard. In the Share dashboard page that opens, under Manage permissions, review the users and groups, and their roles and settings. You can search to locate a specific user or group by entering their name or any part of their name in the search box at upper right. Searching is case-sensitive, and wildcards aren't supported. Delete the search term to return the view to all users.
Comment: B. Create an analysis in Amazon QuickSight. Connect all the data sources and create new datasets. Publish dashboards to visualize the data. Share the dashboards with the appropriate users and groups. Amazon QuickSight is a business intelligence (BI) tool provided by AWS that allows you to create interactive dashboards and reports. It supports a variety of data sources, including Amazon S3 and Amazon RDS for PostgreSQL, which are the data sources in the company's data lake. Option A (Create an analysis in Amazon QuickSight and share with IAM roles) is incorrect because it suggests sharing with IAM roles, which are more suitable for managing access to AWS resources rather than granting access to specific users or groups within QuickSight.
Comment: Explanation: Option B involves using Amazon QuickSight, which is a business intelligence tool provided by AWS for data visualization and reporting. With this option, you can connect all the data sources within the data lake, including Amazon S3 and Amazon RDS for PostgreSQL. You can create datasets within QuickSight that pull data from these sources. The solution allows you to publish dashboards in Amazon QuickSight, which will provide the required data visualization capabilities. To control access, you can use appropriate IAM (Identity and Access Management) roles, assigning full access only to the company's management team and limiting access for the rest of the company. You can share the dashboards selectively with the users and groups that need access.
Comment: My opinion is divided here, and I will explain: Option C can be correct because glue crawler is used to access S3, and athena federated query is used to access RDS. My problem with answer C is that it says: "Generate Reports by using athena" And I think that is not true. athena alone does not generate reports, it has to integrate with services such as quickSight and then it generates reports, therefore the answer is not written properly and I think C is a mistake. Since C is wrong I think B is the correct answer.
Comment: Explanation: Option B involves using Amazon QuickSight, which is a business intelligence tool provided by AWS for data visualization and reporting. With this option, you can connect all the data sources within the data lake, including Amazon S3 and Amazon RDS for PostgreSQL. You can create datasets within QuickSight that pull data from these sources. The solution allows you to publish dashboards in Amazon QuickSight, which will provide the required data visualization capabilities. To control access, you can use appropriate IAM (Identity and Access Management) roles, assigning full access only to the company's management team and limiting access for the rest of the company. You can share the dashboards selectively with the users and groups that need access.
Comment: Ans B - as well explained by PhucVuu
Comment: CoPilot says B - Amazon QuickSight is a fully managed business intelligence (BI) service that allows you to create interactive dashboards and visualizations. It integrates seamlessly with various data sources, including Amazon S3 and Amazon RDS. You can define fine-grained access control using QuickSight's permissions and user roles. Configure access so that only the management team has full access to all visualizations, while other users have limited access based on their roles.
Comment: Amazon QuickSight is a fast, cloud-powered business intelligence (BI) service that focuses on data visualization and reporting. It allows users to connect various data sources, create interactive dashboards, and share those dashboards with others.
Comment: Amazon QuickSight can connect to various data sources within a data lake.
Comment: CD: AWS Glue is ETL so not required here A: Doable but IAM roles is not provided for each user so this cannot be implemented B: Correct, QuickSight can be used for visualisation reports from S3 and RDS . Comapny's management team sounds like an appropriate role for distribution.
Comment: Answer- B
Comment: I will go with B after watching the video on this link
Comment: Always remember that you should associate IAM roles to EC2 instances
Comment: The correct option to meet this requirement is A: Create an IAM role that grants access to the S3 bucket and attach the role to the EC2 instances. An IAM role is an AWS resource that allows you to delegate access to AWS resources and services. You can create an IAM role that grants access to the S3 bucket and then attach the role to the EC2 instances. This will allow the EC2 instances to access the S3 bucket and the documents stored within it. Option B is incorrect because an IAM policy is used to define permissions for an IAM user or group, not for an EC2 instance. Option C is incorrect because an IAM group is used to group together IAM users and policies, not to grant access to resources. Option D is incorrect because an IAM user is used to represent a person or service that interacts with AWS resources, not to grant access to resources.
Comment: Ans A - as per "Buruguduystunstugudunstuy" response.
Comment: Answer-A
Comment: Below is the response from Amazon Q: To access S3 from an EC2 instance, you need to create an IAM role and associate that role with the EC2 instance. Here are the basic steps: 1. Create an IAM role and attach the AmazonS3ReadOnlyAccess or AmazonS3FullAccess managed policy to grant S3 access. 2. Launch the EC2 instance and select the IAM role you created during launch. 3. The instance will now have the permissions defined in the IAM role and you can access S3 from the instance.
Comment: Some key points: 1. Attaching an IAM role is preferred over creating a resource-based policy for S3 access from EC2 as it provides centralized access management. 2. The instance will need internet access to communicate with S3. Make sure the associated security group and NACL rules allow outbound internet access. 3. Check AWS documentation for latest steps to create and associate an IAM role with an EC2 instance. The console and CLI provide options to automate this process.
Comment: Strangely straight forward, Almost had me confused.
Comment: For sure
Comment: The correct option to meet this requirement is A: Create an IAM role that grants access to the S3 bucket and attach the role to the EC2 instances. An IAM role is an AWS resource that allows you to delegate access to AWS resources and services. You can create an IAM role that grants access to the S3 bucket and then attach the role to the EC2 instances. This will allow the EC2 instances to access the S3 bucket and the documents stored within it. Option B is incorrect because an IAM policy is used to define permissions for an IAM user or group, not for an EC2 instance. Option C is incorrect because an IAM group is used to group together IAM users and policies, not to grant access to resources. Option D is incorrect because an IAM user is used to represent a person or service that interacts with AWS resources, not to grant access to resources.
Comment: EC2 instances should be associated with IAM roles. Policies can be applying to users and groups can help to apply multiple roles.
Comment: Option B may work but , suggests creating an IAM policy directly and attaching it to the EC2 instances. While this might work, it's not the recommended approach. Using an IAM role is more secure and manageable.
Comment: Always remember that you should associate IAM roles to EC2 instances. An IAM role is an AWS resource that allows you to delegate access to AWS resources and services. You can create an IAM role that grants access to the S3 bucket and then attach the role to the EC2 instances. This will allow the EC2 instances to access the S3 bucket and the documents stored within it.
Comment: IAM roles should be associated to EC2 instance
Comment: Option A MET THE REQUIREMENT
Comment: Option A is the correct approach because IAM roles are designed to provide temporary credentials to AWS resources such as EC2 instances. By creating an IAM role, you can define the necessary permissions and policies that allow the EC2 instances to access the S3 bucket securely. Attaching the IAM role to the EC2 instances will automatically provide the necessary credentials to access the S3 bucket without the need for explicit access keys or secrets. Option B is not recommended in this case because IAM policies alone cannot be directly attached to EC2 instances. Policies are usually attached to IAM users, groups, or roles. Option C is not the most appropriate choice because IAM groups are used to manage collections of IAM users and their permissions, rather than granting access to specific resources like S3 buckets. Option D is not the optimal solution because IAM users are intended for individual user accounts and are not the recommended approach for granting access to resources within EC2 instances.
Comment: IAM Roles manage who/what has access to your AWS resources, whereas IAM policies control their permissions. Therefore, a Policy alone is useless without an active IAM Role or IAM User.
Comment: A is correct
Comment: always role for ec2 instance
Comment: To design a solution that uses durable, stateless components to process images automatically, a solutions architect could consider the following actions: Option A involves creating an SQS queue and configuring the S3 bucket to send a notification to the queue when an image is uploaded. This allows the application to decouple the image upload process from the image processing process and ensures that the image processing process is triggered automatically when a new image is uploaded. Option B involves configuring the Lambda function to use the SQS queue as the invocation source. When the SQS message is successfully processed, the message is deleted from the queue. This ensures that the Lambda function is invoked only once per image and that the image is not processed multiple times.
Comment: Option C is incorrect because it involves storing state (the file name) in memory, which is not a durable or scalable solution. Option D is incorrect because it involves launching an EC2 instance to monitor the SQS queue, which is not a stateless solution. Option E is incorrect because it involves using Amazon EventBridge (formerly Amazon CloudWatch Events) to send an alert to an Amazon Simple Notification Service (Amazon SNS) topic, which is not related to the image processing process.
Comment: So storing states invokes the stateless principle, nice understanding!
Comment: A stateless system sends a request to the server and relays the response (or the state) back without storing any information. On the other hand, stateful systems expect a response, track information, and resend the request if no response is received
Comment: It looks like A-B
Comment: Keywords: - Store the image in an Amazon S3 bucket, process and compress the image with an AWS Lambda function. - Durable, stateless components to process the images automatically A,B: Correct - SQS has message retention function(store message) default 4 days(can increate update 14 days) so that you can re-run lambda if there are any errors when processing the images. C: Incorrect - Lambda function just run the request then stop, the max tmeout is 15 mins. So we cannot store data in the ram of Lambda function. D: Incorrect - we can trigger Lambda dirrectly from SQS no need EC2 instance in this case E: Incorrect - It kinds of manually step -> the owner has to read email then process it :))
Comment: Explanation: Option A: By creating an Amazon SQS queue and configuring the S3 bucket to send a notification to the SQS queue when an image is uploaded, the system establishes a durable and scalable way to handle incoming image processing tasks. Option B: Configuring the Lambda function to use the SQS queue as the invocation source allows it to retrieve messages from the queue and process them in a stateless manner. After successfully processing the image, the Lambda function can delete the message from the queue to avoid duplicate processing.
Comment: A. Create an Amazon Simple Queue Service (Amazon SQS) queue. Configure the S3 bucket to send a notification to the SQS queue when an image is uploaded to the S3 bucket. B. Configure the Lambda function to use the Amazon Simple Queue Service (Amazon SQS) queue as the invocation source. When the SQS message is successfully processed, delete the message in the queue. Explanation: A (SQS Queue): Using SQS to decouple the S3 bucket from the processing components provides durability and scalability. When an image is uploaded, a notification is sent to the SQS queue. B (Lambda with SQS Trigger): Configuring the Lambda function to use the SQS queue as the invocation source allows for stateless and scalable image processing. Lambda can be triggered by messages in the SQS queue, and upon successful processing, the message can be deleted, ensuring that each message (image) is processed once. This combination ensures a durable, stateless, and scalable architecture for processing images automatically in response to user uploads.
Comment: Option A is a correct because it allows for decoupling between the image upload process and image processing. By configuring S3 to send a notification to SQS, image upload event is recorded and can be processed independently by microservice. Option B is also a correct because it ensures that Lambda is triggered by messages in SQS. Lambda can retrieve image information from SQS, process and compress image, and store compressed image in a different S3. Once processing is successful, Lambda can delete processed message from SQS, indicating that image has been processed. Option C is not recommended because it introduces a stateful approach by using a text file to keep track of processed images. Option D is not optimal solution as it introduces unnecessary complexity by involving an EC2 to monitor SQS and maintain a text file. Option E is not directly related to requirement of processing images automatically. Although EventBridge and SNS can be useful for event notifications and further processing, they don't provide the same level of durability and scalability as SQS.
Comment: Ans A,B - as per Buruguduystunstugudunstuy's response: stateless, robust
Comment: whenever we talk about microservices we should mention SQS, so A and B are the right answers
Comment: A/B make the most sense and in practice this works, I've done it.
Comment: Answer- A,B
Comment: I can not understand why it is not as simple like s3-1 event destination to notify the lambda function to process and upload to s3-2
Comment: Option AB MET THE REQUIREMENT
Comment: D and E are distractions. C seems a valid solution. However, as you have to select two, A and B are the only two that work in conjunction with each other.
Comment: A and B are optimal solutions
Comment: Option A nad B
Comment: A and B
Comment: A. Create an Amazon Simple Queue Service (Amazon SQS) queue. Configure the S3 bucket to send a notification to the SQS queue when an image is uploaded to the S3 bucket. B. Configure the Lambda function to use the Amazon Simple Queue Service (Amazon SQS) queue as the invocation source. When the SQS message is successfully processed, delete the message in the queue.
Comment: Answer is D . Use Gateway Load balancer
Comment: It's D, Coz.. Gateway Load Balancer is a new type of load balancer that operates at layer 3 of the OSI model and is built on Hyperplane, which is capable of handling several thousands of connections per second. Gateway Load Balancer endpoints are configured in spoke VPCs originating or receiving traffic from the Internet. This architecture allows you to perform inline inspection of traffic from multiple spoke VPCs in a simplified and scalable fashion while still centralizing your virtual appliances.
Comment: The solution that will meet these requirements with the least operational overhead is D: Deploy a Gateway Load Balancer in the inspection VPC and create a Gateway Load Balancer endpoint to receive the incoming packets and forward the packets to the appliance. A Gateway Load Balancer is a fully managed service that provides a single point of contact for clients and distributes incoming traffic across multiple targets, such as Amazon Elastic Compute Cloud (EC2) instances and containers, in one or more virtual private clouds (VPCs). You can deploy a Gateway Load Balancer in the inspection VPC and create a Gateway Load Balancer endpoint to receive the incoming packets from the web servers in the application's VPC and forward the packets to the appliance for packet inspection. This will allow you to inspect all traffic to the web application with minimal operational overhead.
Comment: Option A is incorrect because a Network Load Balancer is designed to handle traffic at the connection level and is not suitable for packet inspection. Option B is incorrect because an Application Load Balancer is designed to handle traffic at the request level and is not suitable for packet inspection. Option C is incorrect because a transit gateway is designed to allow multiple VPCs and on-premises networks to connect to each other, but it is not suitable for packet inspection.
Comment: D. Deploy a Gateway Load Balancer in the inspection VPC. Create a Gateway Load Balancer endpoint to receive the incoming packets and forward the packets to the appliance. A Gateway Load Balancer can inspect traffic before forwarding it to a virtual appliance for additional processing. The solution will not require changing the existing architecture and will have the least amount of operational overhead. The appliance can be configured with a specific IP interface to accept IP packets. The Gateway Load Balancer can be configured with an endpoint to route incoming packets to the appliance. The solution ensures all traffic to the web application is inspected before it reaches the web server.
Comment: Keywords:Third-party virtual firewall appliance from AWS Marketplace in an inspection VPC -> only Gateway Load Balancer support it A: Incorrect - Network Load Balancer don't support to route traffic to third-party virtual firewall appliance. B: Incorrect - Application Load Balancer don't support to route traffic to third-party virtual firewall appliance. C: Incorrect - Transit Gateway is use as connect center to connect all VPC, Direct Connect Gateway and VPN Connection. Routes Tables in Trasit Gateway only limit which VPC can talk to other VPCs. D: Correct - Gateway Load Balancer support route traffic to third-party virtual firewall appliance in layer 3 that make it different from ALB and NLB.
Comment: In the scenario described, the web servers, application servers, and database servers are all located within the same VPC. Therefore, a Gateway Load Balancer may not be the most suitable choice for load balancing traffic between them. Instead, an Application Load Balancer (ALB) would be a better option as it operates at Layer 7 and can inspect traffic at the application layer. This would allow the virtual firewall to inspect traffic before it reaches the web servers, which is the requirement specified in the scenario. Overall, while a Gateway Load Balancer can be useful in certain scenarios, it is not the best choice for this particular use case. An Application Load Balancer is a better option as it provides the necessary features to integrate the web application with the virtual firewall appliance and inspect all traffic before it reaches the web server.
Comment: Here's why Traffic enters the service consumer VPC through the internet gateway. Traffic is sent to the Gateway Load Balancer endpoint, as a result of ingress routing. Traffic is sent to the Gateway Load Balancer for inspection through the security appliance. Traffic is sent back to the Gateway Load Balancer endpoint after inspection. Traffic is sent to the application servers (destination subnet). https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html But I ain't completely sure about the least operational overhead.
Comment: This is the answer of ChatGpt: Option B is the correct solution because the ALB can be used to redirect traffic to the virtual firewall appliance without requiring any changes to the backend application servers. The ALB can also be configured to send traffic to multiple targets, allowing the architect to perform high availability and load balancing. This solution is easy to implement and manage and does not require any additional components such as transit gateways or gateway load balancers. Option D is not the optimal solution since Gateway Load Balancer (GWLB) is intended for use with virtual appliances in the cloud, such as firewalls and intrusion prevention systems. However, it adds operational overhead since creating and managing a Gateway Load Balancer requires several components, including an endpoint group and listener.
Comment: A. Create a Network Load Balancer in the public subnet of the application's VPC to route the traffic to the appliance for packet inspection. By creating a Network Load Balancer (NLB) in the public subnet, you can configure it to forward incoming traffic to the virtual firewall appliance for inspection. The NLB operates at the transport layer (Layer 4) and can distribute traffic across multiple instances, including the firewall appliance. This allows you to scale the inspection capacity if needed. The NLB can be associated with a target group that includes the IP address of the firewall appliance, directing traffic to it before reaching the web servers. Option B (Application Load Balancer) is not suitable for this scenario as it operates at the application layer (Layer 7) and does not provide direct access to the IP packets for inspection. Option C (Transit Gateway) and option D (Gateway Load Balancer) introduce additional complexity and overhead compared to using an NLB. They are not necessary for achieving the requirement of inspecting traffic to the web application before reaching the web servers.
Comment: best answer.well explained
Comment: The correct answer is D. Here is the explanation: Option D is correct because a Gateway Load Balancer (GWLB) is a global service, and it can be deployed in any VPC. This means that the GWLB can reach the appliance. Additionally, the GWLB can be configured to forward packets to the appliance for packet inspection. Option A is incorrect because a Network Load Balancer (NLB) is a regional service, and the appliance is deployed in an inspection VPC. This means that the NLB would not be able to reach the appliance. Option B is incorrect because an Application Load Balancer (ALB) is a regional service, and the appliance is deployed in an inspection VPC. This means that the ALB would not be able to reach the appliance. Option C is incorrect because a transit gateway is a global service, and the appliance is deployed in an inspection VPC. This means that the transit gateway would not be able to reach the appliance.
Comment: Gateway Load Balancer (GWLB): GWLB is designed for deploying third-party appliances and provides a scalable and easy way to route traffic through appliances. It operates at the network layer and can handle both TCP and UDP traffic. Operational Overhead: Deploying a GWLB in the inspection VPC and creating an endpoint involves less operational overhead compared to managing Load Balancers in the application's VPC. It allows for centralized management of the inspection process. This solution ensures that all traffic is routed through the Gateway Load Balancer for inspection before reaching the web servers, providing a scalable and efficient way to integrate the third-party virtual firewall appliance
Comment: A and B are wrong, as they don' t support cross-VPC traffic routing Option C -transit gateway attached to VPC,updating route table and configure security groups and network ACLs can accomplish the task. Meanwhile, Gateway load balancer is designed meant for routing traffic across VPC, but itself alone does not work. All effort mentioned is C are still required. So this is not the least effort?
Comment: Ans B – (a) because it's at the right level, ie. application level packet inspection; (b) it states “packet inspection” and fulfils the conditions: -“LEAST operational overhead” -“…to inspect all traffic to the application before the traffic reaches the web” GLB won't do it – because it states “receive the incoming packets and forward the packets to the appliance” – ie. NO inspection: the application gets the packet (good or bad!).
Comment: I agree with you as long as the question didn't mention anything about scalability and high availability for the network appliance.
Comment: D : Gateway Load balancer : use when you have virtual appliances like IDP/IPS(instruction detection, prevention system.. ) & Firewall etc
Comment: Gateway Load Balancers make it easy to deploy, scale, and manage third-party virtual appliances, such as security appliances.
Comment: selected answer: D Gateway Load Balancers make it easy to deploy, scale, and manage third-party virtual appliances, such as security appliances.
Comment: Intrusion prevention systems (IPS) is the main use case for gateway load Balancers. If you see a scenario for virtual Firewall Appliance, the answer is most likely to be GLB.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html Amazon EBS fast snapshot restore (FSR) enables you to create a volume from a snapshot that is fully initialized at creation. This eliminates the latency of I/O operations on a block when it is accessed for the first time. Volumes that are created using fast snapshot restore instantly deliver all of their provisioned performance.
Comment: Keywords: - Modifications to the cloned data must not affect the production environment. - Minimize the time that is required to clone the production data into the test environment. A: Incorrect - we can do this But it is not minimize the time as requirement. B: Incorrect - This approach use same EBS volumes for produciton and test. If we modify test then it will be affected prodution environment. C: Incorrect - EBS snapshot will create new EBS volumes. It can not restore from existing volumes. D: Correct - Turn on the EBS fast snapshot restore feature on the EBS snapshots -> no latency on first use
Comment: Ans D - as per PhucVuu response... what's to debate...
Comment: Ye its d cuh
Comment: https://docs.aws.amazon.com/ebs/latest/userguide/ebs-restoring-volume.html Its C. reate a new volume from the snapshot. Use the create-volume command. For --snapshot-id, specify the ID of the snapshot to use. For --availability-zone, specify the same Availability Zone as the instance. Configure the remaining parameters as needed.
Comment: Answer is D because volumes that are created using fast snapshot restore instantly deliver all of their provisioned performance. Volumes created from normal snapshots will take time to initialize
Comment: A: Can work but long cloning time B: Wrong as multi attach will mean changes by test will affect production C: Slow D: Fast restore makes this a quicker option
Comment: Answer-D
Comment: Amazon EBS fast snapshot restore (FSR) enables you to create a volume from a snapshot that is fully initialized at creation. This eliminates the latency of I/O operations on a block when it is accessed for the first time. Volumes that are created using fast snapshot restore instantly deliver all of their provisioned performance.
Comment: why not A? high I/O, no need durability
Comment: Although it is test environment, it's data should be durable
Comment: Needs to minimize the time that is required to clone the production data into the test environment = EBS fast snapshot restore feature
Comment: Option C provides an effective solution for cloning large amounts of production data into a test environment with minimized time, high I/O performance, and without affecting the production environment.
Comment: But you don't need a new, empty volume, you need a restore of the PROD snapshot. Thus D.
Comment: The correct answer is D. Here is a step-by-step explanation of how to clone production data into a test environment using EBS snapshots: Take EBS snapshots of the production EBS volumes. Turn on the EBS fast snapshot restore feature on the EBS snapshots. Restore the snapshots into new EBS volumes. Attach the new EBS volumes to EC2 instances in the test environment. The EBS fast snapshot restore feature allows you to restore snapshots more quickly than the default method. This is because the feature uses a process called parallel restore, which allows multiple EBS volumes to be restored at the same time. The EBS fast snapshot restore feature is only available for EBS snapshots that are created in the same AWS Region as the EC2 instances that you are using to restore the snapshots.
Comment: For consistently high IO, option A is the solution. Instance store has the highest IO
Comment: Its not, D its the solution. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html
Comment: Option D is the ideal answer.
Comment: Take EBS snapshots of the production EBS volumes. Turn on the EBS fast snapshot restore feature on the EBS snapshots. Restore the snapshots into new EBS volumes. Attach the new EBS volumes to EC2 instances in the test environment. Enabling the EBS fast snapshot restore feature allows you to restore EBS snapshots into new EBS volumes almost instantly, without needing to wait for the data to be fully copied from the snapshot. This significantly reduces the time required to clone the production data. By taking EBS snapshots of the production EBS volumes and restoring them into new EBS volumes in the test environment, you can ensure that the cloned data is separate and does not affect the production environment. Attaching the new EBS volumes to the EC2 instances in the test environment allows you to access the cloned data.
Comment: Amazon EBS fast snapshot restore (FSR) enables you to create a volume from a snapshot that is fully initialized at creation. This eliminates the latency of I/O operations on a block when it is accessed for the first time. Volumes that are created using fast snapshot restore instantly deliver all of their provisioned performance.
Comment: D because all of the components are infinitely scalable dynamoDB, API Gateway, Lambda, and of course s3+cloudfront
Comment: The solution that will meet these requirements with the least operational overhead is D: Use an Amazon S3 bucket to host the website's static content, deploy an Amazon CloudFront distribution, set the S3 bucket as the origin, and use Amazon API Gateway and AWS Lambda functions for the backend APIs. Store the data in Amazon DynamoDB. Using Amazon S3 to host static content and Amazon CloudFront to distribute the content can provide high performance and scale for websites with millions of requests each hour. Amazon API Gateway and AWS Lambda can be used to build scalable and highly available backend APIs to support the website, and Amazon DynamoDB can be used to store the data. This solution requires minimal operational overhead as it leverages fully managed services that automatically scale to meet demand.
Comment: Option A is incorrect because using multiple S3 buckets to host the full website would not provide the required performance and scale for millions of requests each hour with millisecond latency. Option B is incorrect because deploying the full website on EC2 instances and using an Application Load Balancer (ALB) and an RDS database would require more operational overhead to maintain and scale the infrastructure. Option C is incorrect because while deploying the application in containers and hosting them on Amazon Elastic Kubernetes Service (EKS) can provide high performance and scale, it would require more operational overhead to maintain and scale the infrastructure compared to using fully managed services like S3 and CloudFront.
Comment: Option D: Use Amazon S3 to store the website's static content (like images, HTML, etc.). Static content doesn't change based on user input, so S3 is perfect because it's highly scalable and can handle millions of requests. Use Amazon CloudFront to distribute the content globally, reducing latency by delivering it from servers close to the user. For backend operations (like placing orders), use API Gateway and Lambda functions. API Gateway handles incoming requests, while Lambda runs code without needing servers (it's serverless), which automatically scales to meet the traffic demand. Store the data in DynamoDB: DynamoDB is a fully managed, NoSQL database that can handle huge traffic spikes with very fast performance, which is important for millions of visitors.
Comment: My first answer is C. Coz it's high performance and high scalability. I didn't get the D answer: (1) So S3 can host static website? also is it mentioned on the question? (2) Lambda, S3, DynamoDB, all service managed by AWS, but so what, same with (1), which component host the main page?
Comment: D operational overhead Lamda is a serverless computing let you run code without provisioning or managing service API Gateway -> Lamda -> Dynamo DB
Comment: can someone pls tell me how d is the answer. doesn't lambda time out in 15min
Comment: While everyone is voting for D but no where in the question it mentions that website is made of static pages. Other than not mentioning static, option D checks all the boxes.
Comment: I struggled between A and D a little bit, then realize that A is not correct because it's hosting website in "different" buckets.
Comment: Least operational overhead is only possible with managed services that deliver the required solution. A: Cannot store order data in S3 as there is no processing in S3 B: Overhead of EC2 and RDS and ALB, too many moving parts C: Container management is overhead and RDS too D: S3 for static is best practice. CloudFront helps with scaling. API GW with Lambda is fully managed. DynamoDB for transactions is managed scalable solution.
Comment: Answer-D
Comment: D is the best asnwer for least operation
Comment: D because it is the most logical solution
Comment: correct answer
Comment: So in this question, how do you know FOR SURE that the website is static because it does not give you any clues. I know the API gateway makes the most sense with "millions of requests each hour", but it's very vague and leaves a grey area if the web site is static or not.
Comment: 1 deal a day, which is a static content for 24 hours.
Comment: Using Amazon S3 to host static content and Amazon CloudFront to distribute the content can provide high performance and scale for websites with millions of requests each hour. Amazon API Gateway and AWS Lambda can be used to build scalable and highly available backend APIs to support the website, and Amazon DynamoDB can be used to store the data. This solution requires minimal operational overhead as it leverages fully managed services that automatically scale to meet demand.
Comment: static cache in CloudFront can help to handle millions traffic and every 24 hours data can be in store DynamoDB to maintain data for past traffic to get analyzed
Comment: Autoscale with least Ops = AWS managed services: Dynamo DB, API Gateway, Lambda, S3, CF.
Comment: "unpredictable pattern" - always go for Intelligent Tiering of S3 It also meets the resiliency requirement: "S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive redundantly store objects on multiple devices across a minimum of three Availability Zones in an AWS Region" https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html
Comment: The storage option that meets these requirements is B: S3 Intelligent-Tiering. Amazon S3 Intelligent Tiering is a storage class that automatically moves data to the most cost-effective storage tier based on access patterns. It can store objects in two access tiers: the frequent access tier and the infrequent access tier. The frequent access tier is optimized for frequently accessed objects and is charged at the same rate as S3 Standard. The infrequent access tier is optimized for objects that are not accessed frequently and are charged at a lower rate than S3 Standard. S3 Intelligent Tiering is a good choice for storing media files that are accessed frequently and infrequently in an unpredictable pattern because it automatically moves data to the most cost-effective storage tier based on access patterns, minimizing storage and retrieval costs. It is also resilient to the loss of an Availability Zone because it stores objects in multiple Availability Zones within a region.
Comment: Option A, S3 Standard, is not a good choice because it does not offer the cost optimization of S3 Intelligent-Tiering. Option C, S3 Standard-Infrequent Access (S3 Standard-IA), is not a good choice because it is optimized for infrequently accessed objects and does not offer the cost optimization of S3 Intelligent-Tiering. Option D, S3 One Zone-Infrequent Access (S3 One Zone-IA), is not a good choice because it is not resilient to the loss of an Availability Zone. It stores objects in a single Availability Zone, making it less durable than other storage classes.
Comment: Ans B - Intelligent Tiering: cost effective, optimised by access frequency
Comment: S3 intelligent tiering support 3 layer, frequent access, infrequent access and rarely access data. https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html
Comment: Unpredictable pattern equals intelligent tiering
Comment: unpredictable pattern == S3 IA (Intellgent Tiering, not Infrequent access though)
Comment: Unpredictable pattern = Intelligent tiering
Comment: Answer-B
Comment: The right answer due to "unpredictable pattern"
Comment: B because intelligent tiering is what we choose when we don't have a pattern
Comment: Amazon S3 Intelligent Tiering is a storage class that automatically moves data to the most cost-effective storage tier based on access patterns. It can store objects in two access tiers: the frequent access tier and the infrequent access tier. The frequent access tier is optimized for frequently accessed objects and is charged at the same rate as S3 Standard. The infrequent access tier is optimized for objects that are not accessed frequently and are charged at a lower rate than S3 Standard.
Comment: (B) The question mentions that some files are accessed frequently while others are rarely accessed, and the pattern is unpredictable. This makes S3 Intelligent-Tiering a good fit because it automatically moves data between different access tiers based on how frequently they are accessed, optimizing costs. Intelligent-Tiering is designed to optimize costs by automatically moving data to the most cost-effective access tier, without performance impact or operational overhead. B meets the requirements
Comment: Amazon S3 Intelligent Tiering is a storage class that automatically moves data to the most cost-effective storage tier based on access patterns.
Comment: Unpredictable pattern, intelligent tiering will handle that. B - is the answer..
Comment: Files are accessed in an unpredictable pattern, must minimize the costs of storing and retrieving the media files = S3 Intelligent-Tiering.
Comment: S3 Intelligent-Tiering: This storage class is designed to optimize costs by automatically moving objects between two access tiers based on their usage patterns. It uses frequent access and infrequent access tiers. The frequently accessed objects stay in the frequent access tier, while the objects that are not accessed frequently are moved to the infrequent access tier. Intelligent-Tiering maintains high availability across AZs, just like S3 Standard, but it also helps reduce costs by moving data to the lower-cost tier when appropriate.
Comment: Option B is the right answer for this.
Comment: The storage solution that will meet these requirements most cost-effectively is B: Create an S3 Lifecycle configuration to transition objects from S3 Standard to S3 Glacier Deep Archive after 1 month. Amazon S3 Glacier Deep Archive is a secure, durable, and extremely low-cost Amazon S3 storage class for long-term retention of data that is rarely accessed and for which retrieval times of several hours are acceptable. It is the lowest-cost storage option in Amazon S3, making it a cost-effective choice for storing backup files that are not accessed after 1 month. You can use an S3 Lifecycle configuration to automatically transition objects from S3 Standard to S3 Glacier Deep Archive after 1 month. This will minimize the storage costs for the backup files that are not accessed frequently.
Comment: Option A, configuring S3 Intelligent-Tiering to automatically migrate objects, is not a good choice because it is not designed for long-term storage and does not offer the cost benefits of S3 Glacier Deep Archive. Option C, transitioning objects from S3 Standard to S3 Standard-Infrequent Access (S3 Standard-IA) after 1 month, is not a good choice because it is not the lowest-cost storage option and would not provide the cost benefits of S3 Glacier Deep Archive. Option D, transitioning objects from S3 Standard to S3 One Zone-Infrequent Access (S3 One Zone-IA) after 1 month, is not a good choice because it is not the lowest-cost storage option and would not provide the cost benefits of S3 Glacier Deep Archive.
Comment: Also S3 Standard-IA & One Zone-IA stores the data for max of 30 days and not indefinitely.
Comment: you want the MOST cost-effectively solution. Glacier DA is the cheapest for archival.
Comment: B: Transition to Glacier deep archive for cost efficiency
Comment: Ans B - Glacier: the files will not be accessed after 1 month; they just need to be retained
Comment: Should apply S3 lifecycle to move not accessed file after 1 month to S3 Glacier Deep Archive.
Comment: Since the files are not accessed after 1 month but need to be kept indefinitely, transitioning them to S3 Standard-Infrequent Access (S3 Standard-IA) would be the best choice.
Comment: not accessed == Galcier -- easy one
Comment: A: Possible but expensive CD: One zone so no guarantee of being stored indefinitely. B: S3GDA is cost effective indefinite storage
Comment: Answer-B
Comment: It's can't be B!! because objects that are archived to S3 Glacier Instant Retrieval and S3 Glacier Flexible Retrieval are charged for a minimum storage duration of 90 days, and S3 Glacier Deep Archive has a minimum storage duration of 180 days.
Comment: But the items must be kept forever, so where's the issue with that?
Comment: I mean, that min duration **before** can move to S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive
Comment: B because since the files should be kept but never accessed we can put them in Deep Archive
Comment: Amazon S3 Glacier Deep Archive is a secure, durable, and extremely low-cost Amazon S3 storage class for long-term retention of data that is rarely accessed and for which retrieval times of several hours are acceptable
Comment: Answer is B
Comment: B as these files will be stored indefinitely after 1 month
Comment: Files are accessed frequently for 1 month = S3 Standard. Files are not accessed after 1 month and must be kept indefinitely at low costs = S3 Glacier Deep Archive. No requirement for low Ops but S3 Lifecycle to the rescue...whoooosh!
Comment: Option B (Create an S3 Lifecycle configuration to transition objects from S3 Standard to S3 Glacier Deep Archive after 1 month) is the most cost-effective storage solution for this specific scenario. It allows you to maintain accessibility for the initial 1 month while achieving significant cost savings in the long term.
Comment: Option B is the right answer for this.
Comment: Correct answer is B
Comment: https://www.examtopics.com/discussions/amazon/view/68306-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: The requested result is a graph, so... A - can't be as the result is a report B - can't be as it is limited to 14 days visibility and the graph has to cover 2 months C - seems to provide graphs and the best option available, as... D - could provide graphs, BUT involves operational overhead, which has been requested to be minimised.
Comment: Cost Explorer, AWS prepares the data about your costs for the current month and the last 12 months: https://aws.amazon.com/aws-cost-management/aws-cost-explorer/
Comment: 12 months data visible on Cost Explorer.
Comment: 14 days? Fam, you ever logged into the console?
Comment: Never be over-confident! check the below AWS link, which mentions the below. Cost Explorer allows customers to understand their spend for the past 14 days at the most granular hourly level. You can monitor your hourly cost and usage to determine appropriate SP/RI commitment or understand peak hour usage. https://aws.amazon.com/aws-cost-management/aws-cost-explorer/features/#:~:text=Cost%20Explorer%20allows%20customers%20to,or%20understand%20peak%20hour%20usage.
Comment: The answer is B because least operational overhead
Comment: Neither the requirement nor answer B state the need for the "most granular hourly level." Correct answer is B.
Comment: B. This is correct because there is no limit of 14 days. Quoted from Amazon "AWS prepares the data about your costs for the current month and the last 12 months, and then calculates the forecast for the next 12 months." (https://aws.amazon.com/aws-cost-management/aws-cost-explorer/).
Comment: Option B: Use AWS Cost Explorer, a tool that makes it easy to view your costs and break them down into categories like EC2 instance types, time periods, and more. With Cost Explorer, you can easily filter the information to see which EC2 instance types caused the increase in costs over the last two months. This lets you do an in-depth analysis without much effort.
Comment: I would have gone for Ans B but apparently the right one is Ans C. I'm not convinced because neither B or C actually determine the root cause – they just point you in the right direction and then you'll need to do some further analysis around resource demand (CPU, storage, network, etc), data/network traffic, what function/ instructions are actually being processed, along with taking a view of the scaling algorithms. On that basis I'd have said Ans B because it requires the LEAST overhead to get to the next step which is the one that matters: the root analysis for vertical scaling.
Comment: AWS Cost explorer will provide your usage and cost by main graph. https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
Comment: I think the highest priority is "with the LEAST operational overhead?". B is very good for "perform an in-depth analysis" but C overwhelming win on cost.
Comment: Both B and D has their merits and achieve the ask of a question. Infact Option D would give more streamlined and automated approach and will be very less overhead once setup.
Comment: Not sure why it's B -- how can cost explorer identify the root cause of the vertical scaling?
Comment: Oh I see why: they want to identify "unwanted vertical scaling of instance types for a couple of EC2 instances", which could be RDS, ES, ElasticCache, and etc: https://aws.amazon.com/aws-cost-management/aws-cost-explorer/features/#:~:text=Cost%20Explorer%20allows%20customers%20to,or%20understand%20peak%20hour%20usage
Comment: Note that If Hourly granularity is required then the correct option might not be B as cost explorer hourly granular details are provided only for past 14 days. reference link - https://aws.amazon.com/aws-cost-management/aws-cost-explorer/features/#:~:text=Cost%20Explorer%20allows%20customers%20to,or%20understand%20peak%20hour%20usage.
Comment: Cost and usage report is the right tool for analyzing and understanding your bill. Cost explorer is mostly used for monitoring usage/expenditure over time to forecast and decide on more suitable plan/ package.
Comment: The answer is B. You can enable Cost Explorer for your account using this procedure on the Billing and Cost Management console. You can't enable Cost Explorer using the API. After you enable Cost Explorer, AWS prepares the data about your costs for the current month and the last 12 months, and then calculates the forecast for the next 12 months. The current month's data is available for viewing in about 24 hours. The rest of your data takes a few days longer. Cost Explorer updates your cost data at least once every 24 hours.
Comment: Cost Explorer
Comment: The option that provides the least operational overhead for generating a graph comparing the last 2 months of EC2 costs based on instance types is: D. Use AWS Cost and Usage Reports to create a report and send it to an Amazon S3 bucket. Use Amazon QuickSight with Amazon S3 as a source to generate an interactive graph based on instance types. This option leverages the AWS Cost and Usage Reports to export detailed billing information to an Amazon S3 bucket. Then, using Amazon QuickSight, you can easily create interactive graphs and perform in-depth analysis based on instance types. This approach provides flexibility and customization in analyzing the cost data with minimal operational overhead.
Comment: While this option will give the most detailed visibility of the cost, its certainly not one with the least operational overhead.
Comment: B is least operational overhead A: Can't do that C: Not granular enough D: Too much operational overhead
Comment: Answer-B
Comment: Honestly... I'm mad with this kind of questions...To be honest, there are several ways to do so, but none of them will affect (in a major way) your day to day operations. I'm just saying, useless questions that adds nothing of value.
Comment: I agree.
Comment: In order to clarify why some chosen C, the limitation is only meant for HOURLY COST. "By enabling hourly granularity you can view your hourly costs up to the past 14 days to track costs during nights or off peak hours." https://aws.amazon.com/about-aws/whats-new/2019/11/aws-cost-explorer-supports-hourly-resource-level-granularity/
Comment: A - refactoring can be a solution, BUT requires a LOT of effort - not the answer B - DynamoDB is NoSQL and Aurora is SQL, so it requires a DB migration... again a LOT of effort, so no the answer C and D are similar in structure, but... C uses SNS, which would notify the 2nd Lambda function... provoking the same bottleneck... not the solution D uses SQS, so the 2nd lambda function can go to the queue when responsive to keep with the DB load process. Usually the app decoupling helps with the performance improvement by distributing load. In this case, the bottleneck is solved by uses queues... so D is the answer.
Comment: Keywords: - Company has to increase the Lambda quotas significantly to handle the high volumes of data that the company needs to load into the database. - Improve scalability and minimize the configuration effort. A: Incorrect - Lambda is Serverless and automatically scale - EC2 instance we have to create load balancer, auto scaling group,.. a lot of things. using native Java Database Connectivity (JDBC) drivers don't improve the performance. B: Incorrect - a lot of things to changes and DynamoDB Accelerator use for cache(read) not for write. C: Incorrect - SNS is use for send notification (e-mail, SMS). D: Correct - with SQS we can scale application well by queuing the data.
Comment: It could be C or D, but Ans D wins because –SNS is Push Mechanism - ‘Other Lambda' function is forced to take message when it might not be ready (or refuse it) –SQS is Pull Mechanism – ‘Other Lambda' function can take next message when its ready to do so SQS is simple and allows better de-coupling.
Comment: uses SQS
Comment: If the throughput is so high that lambda concurrency needs to go beyond 1000, we need to set up a queue to throttle the request.
Comment: D. Set up two Lambda functions, one for receiving information and another for loading data into the database. Integrate them using an Amazon SQS queue. This approach allows for better scalability, maintains the serverless paradigm, and minimizes manual configuration effort. It leverages Amazon SQS as a reliable message queue between Lambda functions. Options A and B introduce complexities and changes in architecture, while Option C introduces an additional service that may not be as suitable for decoupling processes in this scenario.
Comment: SQS will help Lambda scale even more. A EC2 + Tomcat will be slower than Lambda for this usecase B is wrong because the problem is with Lambda scaling not the DB C SNS is not the best option for this usecase when SQS is an option
Comment: Answer-D
Comment: D : other ones just don't make sense
Comment: Sorry, but the question does not make sense by itself. What are you asking for more scalability from an already scalable Lambda function? If you're concerned about the concurrency limits of Lambda function, decoupling just doesn't make sense, since it'll keep even more lambda instances running in a given time period(including 2 phases of execution for each request, let alone the cold start issues). If you're concerned about bottleneck database induced, that'll even be more ridiculous since you're supposed to resolve the scalability issue of the database(e.g. Aurora) instead of decoupling the Lambda function to improve the throughput of this entire data flow.
Comment: i think it is clear that he want to enhance the lambda even more than "The default concurrency limit across all functions per region in a given account is 1,000" cause sqs can scale and store the data till new available revoked lambda consume it
Comment: Lambda and SQS are serverless. No involvement will be required in execution.
Comment: I think B would be better solution. How splitting one function into 2 increase scalability when company already increased service quota? Effectively they will have same compute time. Changing Aurora to DAX will shorten the time for data loads by ~100x requiring way less time for data loading, and it's most time consuming thing this lambda does. DAX has better scaling than aurora and is better fit with lambda
Comment: Lambda Functions: A review Run your code in response to events You can build chatbots using Lambda functions to process user input, execute business logic, and generate responses. Scales automatically They can be triggered in response to API events Lambda functions can process files as they are uploaded to S3 buckets. This is often used for tasks like image resizing, data extraction, or file validation.
Comment: AWS Cost Explorer is a tool that enables you to view and analyze your costs and usage. You can explore your usage and costs using the main graph, the Cost Explorer cost and usage reports, or the Cost Explorer RI reports. You can view data for up to the last 12 months, forecast how much you're likely to spend for the next 12 months, and get recommendations for what Reserved Instances to purchase. Ans: B is correct https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
Comment: Do you all have to take the whole practice exam on here, in order to pass AWS SAA C03
Comment: Increase Lambda quotas = Set up two Lambda functions. Improve scalability = Amazon Simple Queue Service.
Comment: Selected answer D
Comment: Option D is the right answer for this.
Comment: The solution that will accomplish this goal is A: Turn on AWS Config with the appropriate rules. AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. You can use AWS Config to monitor and record changes to the configuration of your Amazon S3 buckets. By turning on AWS Config and enabling the appropriate rules, you can ensure that your S3 buckets do not have unauthorized configuration changes.
Comment: AWS Trusted Advisor (Option B) is a service that provides best practice recommendations for your AWS resources, but it does not monitor or record changes to the configuration of your S3 buckets. Amazon Inspector (Option C) is a service that helps you assess the security and compliance of your applications. While it can be used to assess the security of your S3 buckets, it does not monitor or record changes to the configuration of your S3 buckets. Amazon S3 server access logging (Option D) enables you to log requests made to your S3 bucket. While it can help you identify changes to your S3 bucket, it does not monitor or record changes to the configuration of your S3 bucket.
Comment: Configuration changes= AWS Config
Comment: Ans A - as well explained by "Buruguduystunstugudunstuy" – we are dealing with configuration here: ensuring that what we've designed continues to follow the rules
Comment: ChatGPT give the answer is D
Comment: Answer-A
Comment: A: https://aws.amazon.com/config/#:~:text=How%20it%20works-,AWS%20Config,-continually%20assesses%2C%20audits
Comment: AWS Config continually assesses, audits, and evaluates the configurations and relationships of your resources on AWS, on premises, and on other clouds. It normalizes changes into a consistent format and checks resource compliance with custom and managed rules before and after provisioning. https://aws.amazon.com/config/#:~:text=How%20it%20works-,AWS%20Config,-continually%20assesses%2C%20audits
Comment: AWS Config provides a detailed inventory of the company's AWS resources and configuration history, and can be configured with rules to evaluate resource configurations for compliance with policies and best practices. The solutions architect can enable AWS Config and configure rules specifically checking for S3 bucket settings like public access blocking, encryption settings, access control lists, etc. AWS Config will record configuration changes to S3 buckets over time, allowing the company to review changes and be alerted about any unauthorized modifications. By. Claude.ai
Comment: Option A is the right answer for this.
Comment: AWS Config is a service that provides a detailed view of the configuration of AWS resources in your account. By enabling AWS Config, you can capture configuration changes and maintain a record of resource configurations over time. It allows you to define rules that check for compliance with desired configurations and can generate alerts or automated actions when unauthorized changes occur. To accomplish the goal of preventing unauthorized configuration changes in Amazon S3 buckets, you can configure AWS Config rules specifically for S3 bucket configurations. These rules can check for a variety of conditions, such as ensuring that encryption is enabled, access control policies are correctly configured, and public access is restricted. While options B, C, and D offer valuable services for various aspects of AWS deployment, they are not specifically focused on preventing unauthorized configuration changes in Amazon S3 buckets as effectively as enabling AWS Config.
Comment: Don't be mistaken in thinking that it's Server access logs because that's for detailed records for requests made to S3. It's AWS Config because it records configuration changes.
Comment: AWS truseted Adviser is for providing recommendation only. For any configuration use AWS config Inspecter is for scanning for any software vulnerabilities and unintended network exposure
Comment: To accomplish the goal of ensuring that Amazon S3 buckets do not have unauthorized configuration changes, a solutions architect should turn on AWS Config with the appropriate rules. AWS Config enables continuous monitoring and recording of AWS resource configurations, including S3 buckets. By turning on AWS Config with the appropriate rules, the solutions architect can be notified of any unauthorized changes made to the S3 bucket configurations, allowing for prompt corrective action. Options B, C, and D are not directly related to monitoring and preventing unauthorized configuration changes to Amazon S3 buckets.
Comment: Key words:configuration changes
Comment: Option A is the correct solution. AWS Config is a service that allows you to monitor and record changes to your AWS resources over time. You can use AWS Config to track changes to Amazon S3 buckets and their configuration settings, and set up rules to identify any unauthorized configuration changes. AWS Config can also send notifications through Amazon SNS to alert you when these changes occur.
Comment: aws: A - aws config
Comment: AAAAaaaaaaaaaaaaaaaaa
Comment: Answere A : https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html Share a single dashboard and designate specific email addresses of the people who can view the dashboard. Each of these users creates their own password that they must enter to view the dashboard.
Comment: Thanks for the link! No doubt A is the answer.
Comment: But this link also says All people who you share the dashboard with are granted these permissions for the account. If you share the dashboard publicly, then everyone who has the link to the dashboard has these permissions. The cloudwatch:GetMetricData and ec2:DescribeTags permissions cannot be scoped down to specific metrics or EC2 instances, so the people with access to the dashboard can query all CloudWatch metrics and the names and tags of all EC2 instances in the account. If that is the case, how is the least privilege principle applicable?
Comment: Option B provides the product manager with specific access to the CloudWatch dashboard using an IAM user with the CloudWatchReadOnlyAccess policy attached. The IAM user has only read-only access to the required resources, which follows the principle of least privilege.
Comment: b has a problem for cloudwatchreadonlyacess policy, it's not only grant read access to dashboard, but other read permission for logs, insights, etc. so it does not follows the principle of least privilege. Option A only grants access to dashboard.
Comment: correct answer B the reason A is not a good answer is: when sharing a link to the CloudWatch dashboard the following warning appears We recommend that you do not share dashboards if your account contains any sensitive information which you would not wish to share with the users with whom you are sharing the dashboard. The users that you specified above will be granted the following permissions: CloudWatch read-only permissions to alarms and contributor insights rules in the Dashboard which you share, and to all metrics and the names and tags of all EC2 instances in your account even if they are not shown in the Dashboard which you share. We recommend that you consider whether it is appropriate to make this information available to the users with whom you are sharing. so following the least privilege principle, creating an IAM User in option B is more secure
Comment: The goal is to allow a product manager (who does not have an AWS account) to access a CloudWatch dashboard periodically. B follows the principle of least privilege, ensuring that the product manager can only view the dashboard and not perform any other actions within AWS.Is direct email sharing is not a feature of CloudWatch?
Comment: Least privilege
Comment: A would be indeed following the principle of least privilege, but periodic access means we have to do this time and time again when the product manager requests access. B is better
Comment: Ans B – its tidy and self-contained, and uses IAM roles as the solution should Others: o Ans A – means personalising access by relying upon the Product Manager's email – what if he changes his name or a new Product Manager is hired? o Ans C – too lengthy and introduces potential for mistakes o Ans D – not even sure why this is here…
Comment: Highlight the point least privilege . No user account or no giving access permissions directly sharing link hence ans is A
Comment: A. You can share your CloudWatch dashboards with people who do not have direct access to your AWS account
Comment: B. specifically for the product manager+correct dashboard A is Incorrect. If you share the dashboard publicly, then everyone who has the link to the dashboard has these permissions. This practice can be considered high risk.
Comment: Please note that B does not meet the principle of least privilege, simply because granting CloudWatchReadOnlyAccess would allow this user to read ANY Dashboard or metrics, not only this specific one.
Comment: For anyone thinking it's B. Go and look at the permissions that cloud watch read only access gives you, there is about 20 different ones including from other services e.g. SNS. Sharing the dashboard gives you 4 permissions by default, hence A is the correct answer and actually the recommended method of sharing dashboards. Of course you can then continue to edit the policy after you have shared the dashboard to limit permissions even further, but yes, A is the correct.
Comment: In my opinion answer should B because, Product manager need to access this dashboard "Periodically." so its good that create IAM user and grant specific read only access.("Least privileged access which is another requirement)
Comment: A is definitely NOT the answer. A. Sharing the dashboard from the CloudWatch console and providing a shareable link to the product manager may not align with the principle of least privilege. This method could potentially expose other dashboards or resources in the CloudWatch console that the product manager does not need access to.
Comment: option B (https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchReadOnlyAccess.html) gives way more privilege (including the one where the dashboard is shared (https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html#share-cloudwatch-dashboard-iamrole))
Comment: A is the correct answer considering the manager do not have any AWS account, so you can not create a IAM user.
Comment: Answere B: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html When you share a dashboard, CloudWatch creates an IAM role in the account which gives the following permissions to the people who you share the dashboard with: cloudwatch:GetInsightRuleReport cloudwatch:GetMetricData cloudwatch:DescribeAlarms ec2:DescribeTags A not provide principe of least privilege.
Comment: Option A suggests Sharing of dashboards with temporary credentials while the product manager needs to view it periodically. If your password expires, you need an extra overhead of resetting the password. Thus option B i correct.
Comment: Tricky question!!! forget one-way or two-way. In this scenario, AWS applications (Amazon Chime, Amazon Connect, Amazon QuickSight, AWS Single Sign-On, Amazon WorkDocs, Amazon WorkMail, Amazon WorkSpaces, AWS Client VPN, AWS Management Console, and AWS Transfer Family) need to be able to look up objects from the on-premises domain in order for them to function. This tells you that authentication needs to flow both ways. This scenario requires a two-way trust between the on-premises and AWS Managed Microsoft AD domains. It is a requirement of the application Scenario 2: https://aws.amazon.com/es/blogs/security/everything-you-wanted-to-know-about-trusts-with-aws-managed-microsoft-ad/
Comment: The problem with this is that nowhere in the question is it saying that the application needs to be able to flow back so two-way is not needed.
Comment: AWS IAM Identity Center requires a two-way trust so that it has permissions to read user and group information from your domain to synchronize user and group metadata. IAM Identity Center uses this metadata when assigning access to permission sets or applications. User and group metadata is also used by applications for collaboration, like when you share a dashboard with another user or group. The trust from AWS Directory Service for Microsoft Active Directory to your domain permits IAM Identity Center to trust your domain for authentication. The trust in the opposite direction grants AWS permissions to read user and group metadata.
Comment: What I did find though was documentation that explicitly states that IAM Identity Center (successor to AWS SSO) requires a two-way trust: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html
Comment: Answer B as we have AWS SSO which requires two way trust. As per documentation - A two-way trust is required for AWS Enterprise Apps such as Amazon Chime, Amazon Connect, Amazon QuickSight, AWS IAM Identity Center (successor to AWS Single Sign-On), Amazon WorkDocs, Amazon WorkMail, Amazon WorkSpaces, and the AWS Management Console. AWS Managed Microsoft AD must be able to query the users and groups in your self-managed AD. Amazon EC2, Amazon RDS, and Amazon FSx will work with either a one-way or two-way trust.
Comment: I found the documentation that explicitly states that IAM Identity Center (successor to AWS SSO) requires a two-way trust: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html
Comment: Current version of this question (with Identity Center) doesn't even contain option A. https://www.examtopics.com/discussions/amazon/view/136806-exam-aws-certified-solutions-architect-associate-saa-c03/
Comment: key word: Self Managed. https://docs.aws.amazon.com/singlesignon/latest/userguide/connectonpremad.html
Comment: Two way trust is not required here.
Comment: Right, but with Active Directory, two-way trust is require
Comment: Option B (enabling AWS SSO and creating a two-way forest trust) is the appropriate solution based on the requirement for a two-way trust to support AWS enterprise applications and provide single sign-on capabilities across all AWS accounts while integrating with the on-premises Microsoft Active Directory.
Comment: B for sure
Comment: Options A is enough and will make it work.
Comment: Option A suggests enabling AWS SSO and using a one-way trust, which allows AWS SSO to rely on the on-premises Microsoft Active Directory for authentication while keeping the management centralized in AWS SSO. This is a common and recommended approach for integrating on-premises Active Directory with AWS SSO.
Comment: For the sake of exam options A is enough. Option B rather increases security risk surface.
Comment: I'll go for B as A feels incomplete C Can be done but company wants SSO, not a fill director service D On prem already has a IDP so no.
Comment: Answer-B
Comment: D is better and more applicable in real-world context where everyone chooses simplicity over a overhaul solution; Where Organizations may prefer to continue using their existing, trusted on-premises IdP solutions for authentication, especially if they have specific security policies or compliance requirements.
Comment: Two-way trust or AD Connector. IAM Identity Center only works with those two. "One-way trusts do not work with IAM Identity Center." https://docs.aws.amazon.com/singlesignon/latest/userguide/connectonpremad.html
Comment: Two-way trust or AD Connector. IAM Identity Center only works with those two. "One-way trusts do not work with IAM Identity Center." https://docs.aws.amazon.com/singlesignon/latest/userguide/connectonpremad.html
Comment: From AWS Documentation: A two-way trust is required for AWS Enterprise Apps such as Amazon Chime, Amazon Connect, Amazon QuickSight, AWS IAM Identity Center, Amazon WorkDocs, Amazon WorkMail, Amazon WorkSpaces, and the AWS Management Console. AWS Managed Microsoft AD must be able to query the users and groups in your self-managed AD. Amazon EC2, Amazon RDS, and Amazon FSx will work with either a one-way or two-way trust.
Comment: Option a- and why not option B -Option B, which suggests a two-way forest trust, is generally not recommended unless there are specific reasons for requiring a two-way trust, as it increases complexity and potential security risks.
Comment: agree with A, Global Accelerator has automatic failover and is perfect for this scenario with VoIP https://aws.amazon.com/global-accelerator/faqs/
Comment: I also agree A after reading this link.
Comment: A - Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover. Both services integrate with AWS Shield for DDoS protection.
Comment: This is the best case for A to be an answer. Cloudfront is great but for HTTP use cases.
Comment: Thank you for your link, it make me consolidate A.
Comment: This option does not meet the requirements because AWS Global Accelerator is only used to route traffic to the optimal AWS Region, it does not provide automatic failover between regions.
Comment: Instant regional failover: AWS Global Accelerator automatically checks the health of your applications and routes user traffic only to healthy application endpoints. If the health status changes or you make configuration updates, AWS Global Accelerator reacts instantaneously to route your users to the next available endpoint.
Comment: Thank you, the link also helps me to know the differences between Global Acc and CloudFront.
Comment: CloudFront uses Edge Locations to cache content while Global Accelerator uses Edge Locations to find an optimal pathway to the nearest regional endpoint. CloudFront is designed to handle HTTP protocol meanwhile Global Accelerator is best used for both HTTP and non-HTTP protocols such as TCP and UDP. so i think A is a better answer
Comment: Aws GA is most suitable for https.
Comment: A : UDP so NLB and Global Accelerator reduces the number of hops by providing packets to travel over congestion free AWS global network. Global Accelerator supported end point : ALB,NLB,EC2 & Elastic IP address
Comment: you can configure a Network Load Balancer (NLB) in each AWS Region to address your on-premises endpoints. Then you can register the NLBs as endpoints in your AWS Global Accelerator configuration. https://aws.amazon.com/global-accelerator/faqs/
Comment: UDP Connection :- So NLB Routing to region having lowest latency and also with Automated failover, Also non-HTTP use cases, such as gaming (UDP), or Voice over IP - Global Accelerator
Comment: A is correct because Accelerator endpoint usefull more than route53
Comment: Correct as Global accelerator is most preferred for TCP and UDP
Comment: A ia correct
Comment: A is right answer, key words VoIP, UDP connection, automatic failover between region.
Comment: One of the major benefits of AWS Global Accelerator is Instant regional failover: AWS Global Accelerator automatically checks the health of your applications and routes user traffic only to healthy application endpoints. If the health status changes or you make configuration updates, AWS Global Accelerator reacts instantaneously to route your users to the next available endpoint. https://aws.amazon.com/global-accelerator/faqs/
Comment: Agree with C. As i understand NLB cannot be used as AWS Global accelerator endpoint. It has to be ALB or ELB.
Comment: Its UDP so ALB is not applicable here which means BD are wrong C using CF that uses latency record as origin? Makes no sense B NLB autoscaling and AWS GA is best used for lower latency and scaling. Recommended read: https://aws.amazon.com/blogs/networking-and-content-delivery/well-architecting-online-applications-with-cloudfront-and-aws-global-accelerator/
Comment: Answer-A
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html
Comment: Why ALB, not NLB?
Comment: It IS NLB. You cannot trust the "official" answers. I am not even sure why they bother giving them Application Load Balancer: -Web applications with layer 7 routing (HTTP/HTTPS) -Microservices architectures (e.g. Docker containers) -Lambda targets Network Load Balancer: -TCP and UDP based applications -Ultra low latency -Static IP addresses -VPC endpoint services
Comment: "The company needs to route users to the Region with the lowest latency. The company also needs automated failover between Regions." IMO both A and C would meet both requirements. The main difference is that with A, the IP address stays the same - in case of failover, it would be routed to a different entry point. With C, the different endpoint have different IP addresses, and in case of failover, DNS would return the IP address of a different entry point. Thus failover might take longer with C, but again, the stem does not mention that failover must be fast ...
Comment: Answer C, you still pay for storage when an RDS database is stopped
Comment: C - Create a manual Snapshot of DB and shift to S3- Standard and Restore form Manual Snapshot when required. Not A - By stopping the DB although you are not paying for DB hours you are still paying for Provisioned IOPs , the storage for Stopped DB is more than Snapshot of underlying EBS vol. and Automated Back ups . Not D - Is possible but not MOST cost effective, no need to run the RDS when not needed.
Comment: Ans C – take Snapshots and restore them, because otherwise you're still paying for RDS storage.
Comment: C. This option allows you to save on costs by only paying for storage of the snapshot when the DB instance is terminated. When needed again, you can restore the DB instance from the snapshot, which is a cost-effective way to handle infrequent but resource-intensive tasks.
Comment: Most cost effective is to create a snapshot and get rid of the DB instance after testing. Note that A is not correct option as While your database instance is stopped, you are charged for provisioned storage, manual snapshots and automated backup storage within your specified retention window, but not for database instance hours.
Comment: A Since the tests only run once a month for 48 hours, this approach minimizes costs while still retaining the same compute and memory attributes when the instance is restarted. when Snapshot resorte i new config
Comment: My question is: isn't this DB collecting new data during the testing period ( 48 hrs.) ? after the snapshot is taken ? stop and restore db from the snapshot is the most cost effective but I think some data might be lost in between, so wouldn't be feasible !
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_StopInstance.html
Comment: Answer C because, You can stop a DB instance for up to seven days. If you don't manually start your DB instance after seven days, your DB instance is automatically started so that it doesn't fall behind any required maintenance updates. So, the "auto starting" behaviour is expected. If you rarely use the database, BEST option is to Snapshot and Delete the database. Then, when you need it again, you could launch a new database from the Snapshot. Amazon RDS is not intended to be stopped for long periods.
Comment: DB is used one a month for 48 hours only so there is no point in keeping it up for rest of the month. B: more cost D: not allowed to reduce computing power A: It will work but C is much cheaper as instance is not only stopped but terminated.
Comment: Answer-C
Comment: Option A (Stop and Restart) is less operationally complex and provides a quicker way to resume the database. It's suitable if the primary concern is operational simplicity and quick availability. Option C (Snapshot, Terminate, and Restore) may offer higher cost savings, especially if the instance is large and expensive to run, as you're avoiding charges for the time the instance is down. However, it comes with higher operational complexity and longer lead times to bring the database back online. In Amazon RDS, you do incur charges for a DB instance even when it's stopped. This is a key distinction from Amazon EC2, where you are not charged for instance hours while an EC2 instance is stopped. For RDS, the charges related to the instance's storage and backups continue to accrue even when the instance itself is not running.
Comment: It is C Amazon RDS allows you to easily stop and start your database instances ONLY for up to seven days at a time. So Snapshot and Restore is proper solution.
Comment: Database not used by any other applications/processes, only use 48 hours per month while still need the same compute and RAM for intense testing => stop and start the instance will be the most cost effective. Option C needs to pay for snapshot of DB and more complex for what purpose?
Comment: Sorry, should be C. Key word: Most cost-effective so C - which is taking snapshot is most cost-effective
Comment: Can you please clear my confusion, If the answer is C, What is the use of DB here, when every time DB is terminated and restored from snapshots? Data will remain the same right? If DB is terminated how new data is stored when db is not present
Comment: The Answer is A. Option A does reduce costs when RDS is not running, because RDS does not charge execution fees when it is not running. When an RDS instance is stopped, you only pay the associated storage charges. In Amazon RDS, storage and backup charges are based on the amount of storage you use. Therefore, when you stop an RDS execution instance, you will still pay the costs associated with storage, but not the execution fees. In contrast, if you use option C, which is to take a snapshot and terminate the instance, there may be costs associated with storing the snapshot and Amazon Machine Image (AMI). Overall, option A minimizes costs because when you stop an RDS execution instance, you only have to pay a relatively low storage cost rather than an execution fee.
Comment: A. Stop the DB instance when tests are completed. Restart the DB instance when required. Here's why option A is the most suitable choice: Cost Reduction: Stopping the DB instance when not in use effectively reduces the cost to zero during the idle period. You only pay for storage when the instance is stopped. This is a cost-effective way to handle infrequent, resource-intensive tasks without incurring ongoing costs. Performance Insights Enabled: This option allows you to keep Performance Insights enabled when the DB instance is stopped, which provides visibility into database performance. You can resume the instance and monitor performance during the testing period.
Comment: Answer from ChatGPT: Yes, you can use AWS Config to create tags for your resources. AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. You can use AWS Config to create rules that automatically tag resources when they are created or when their configurations change. To create tags for your resources using AWS Config, you will need to create an AWS Config rule that specifies the tag key and value you want to use and the resources you want to apply the tag to. You can then enable the rule and AWS Config will automatically apply the tag to the specified resources when they are created or when their configurations change.
Comment: This the first answer that I've seen ChatGPT get correct here on ExamTopics. You should all know that using ChatGPT for this is bound to give bad answers. It only parrots what it has seen written/copied/pasted by someone/something somewhere, picked up with absolutely zero context. ChatGPT doesn't "know" anything about AWS services. So, beware the "answers" it gives.
Comment: I tried it with Bing AI, and the answer was almost always the right one. It depends a lot on the prompt quality
Comment: AWS Config provides a set of pre-built or customizable rules that can be used to check the configuration and compliance of AWS resources. By creating a custom rule or using the built-in rule for tagging, you can define the required tags for EC2, RDS DB and Redshift clusters. AWS Config continuously monitors the resources and generates configuration change events or evaluation results. By leveraging AWS Config, the solution can automatically detect any resources that do not comply with the defined tagging requirements. This approach eliminates the need for manual checks or periodic code execution, reducing operational overhead. Additionally, AWS Config provides the ability to automatically remediate non-compliant resources by triggering Lambda or sending notifications, further streamlining the configuration management process. Option B (using Cost Explorer) primarily focuses on cost analysis and does not provide direct enforcement of proper tagging. Option C and D (writing API calls and running them manually or through scheduled Lambda) require more manual effort and maintenance compared to using AWS Config rules.
Comment: Not sure we need ChatGPT here (other than to prove what it can/can't do): answers B, C, D all require manual - and periodic - intervention. Has to be Ans A.
Comment: You can use AWS Config to create a rule that evaluates whether your resources have the required tags applied.
Comment: https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/implementing-and-enforcing-tagging.html AWS Config (required_tag) AWS Config is a service that allows you to assess, audit, and evaluate the configurations of your AWS resources (see Resource types supported by AWS Config). In the case of tagging, we can use it to identify resources that are lacking tags with specific keys, using the required_tags rule (refer to Resource types supported by required_tags). From the earlier example, we might test for the existence of the key on all Amazon EC2 instances.
Comment: Answer-A
Comment: Has typos in the question, correct is "A company that hosts its web application on AWS wants to ensure all Amazon EC2 instance, Amazon RDS DB instances, and Amazon Redshift clusters are configured with tags." Keyword "are configured with tags", choose (A) "AWS Config rules".
Comment: I originally thought D, but after reading through the discussion I agree that option A would require less effort. D would get the job done but would require more effort so I think A is correct.
Comment: A without a doubt
Comment: AWS Config continually assesses, audits, and evaluates the configurations and relationships of your resources on AWS, on premises, and on other clouds.
Comment: Has typos in the question, correct is "A company that hosts its web application on AWS wants to ensure all Amazon EC2 instance, Amazon RDS DB instances, and Amazon Redshift clusters are configured with tags." Keyword "are configured with tags", choose (A) "AWS Config rules".
Comment: Option A is the right answer for this.
Comment: The answer is A
Comment: Option will accomplish the requirements
Comment: AWS Config can track the configuration status of non-compliant resouces :))
Comment: AWS Config can track the configuration status of non-compliant resouces.
Comment: Option A is the most appropriate solution to accomplish the given requirement because AWS Config Rules provide a way to evaluate the configuration of AWS resources against best practices and company policies. In this case, a custom AWS Config rule can be defined to check for proper tag allocation on Amazon EC2 instances, Amazon RDS DB instances, and Amazon Redshift clusters. The rule can be configured to run periodically and notify the responsible parties when a resource is not properly tagged.
Comment: Good answer is B: client-side JavaScript. the website is static, so it must be S3.
Comment: HTML, CSS, client-side JavaScript, and images are all static resources.
Comment: I had initially thought Ans A... but its Ans C -- "cookieMr" makes it clear: Ans A "Containerising the website and hosting with AWS Fargate involves additional complexity and costs associated with managing the container environment and scaling resources." So it has to be... Ans B: "...Amazon S3 to host the website, take advantage of its durability, scalability, and low-cost pricing model. Only pay for the storage and data transfer associated with your website, without the need for managing and maintaining web servers or containers. This reduces the operational overhead and infrastructure costs."
Comment: Cheapest Static site hosting = S3
Comment: Answer-B
Comment: HTML, CSS, client-side JavaScript, and images are all static resources.
Comment: The MOST cost-effective method for hosting a website is to: Create an Amazon S3 bucket and host the website there. Amazon S3 is a highly scalable and cost-effective object storage service. It is a good option for hosting static websites, such as the website in this scenario. To host a static website on Amazon S3, you would first need to create an S3 bucket. Then, you would need to upload the website files to the bucket. Once the files are uploaded, you can configure the bucket to serve as a website.
Comment: Static website should work fine with S3
Comment: the website is static because the backend runs on client side.
Comment: all static resources.
Comment: static website, cost-effective = S3 web hosting
Comment: Just all static content HTML, CSS, client-side JavaScript, images. Amazon S3 is good enough.
Comment: Option B is the right answer for this.
Comment: S3 is amongst the cheapest services offered by AWS.
Comment: B is the correct answer.
Comment: By using Amazon S3 to host the website, you can take advantage of its durability, scalability, and low-cost pricing model. You only pay for the storage and data transfer associated with your website, without the need for managing and maintaining web servers or containers. This reduces the operational overhead and infrastructure costs. Containerizing the website and hosting it in AWS Fargate (option A) would involve additional complexity and costs associated with managing the container environment and scaling resources. Deploying a web server on an Amazon EC2 instance (option C) would require provisioning and managing the EC2 instance, which may not be cost-effective for a static website. Configuring an Application Load Balancer with an AWS Lambda target (option D) adds unnecessary complexity and may not be the most efficient solution for hosting a static website.
Comment: Option B is the MOST cost-effective for hosting the website.
Comment: I would go for C. The tricky phrase is "near-real-time solution", pointing to Firehouse, but it can't send data to DynamoDB, so it leaves us with C as best option. Kinesis Data Firehose currently supports Amazon S3, Amazon Redshift, Amazon OpenSearch Service, Splunk, Datadog, NewRelic, Dynatrace, Sumologic, LogicMonitor, MongoDB, and HTTP End Point as destinations. https://aws.amazon.com/kinesis/data-firehose/faqs/#:~:text=Kinesis%20Data%20Firehose%20currently%20supports,HTTP%20End%20Point%20as%20destinations.
Comment: This was a really tough one. But you have the best explanation on here with reference point. Thanks. I'm going with answer C!
Comment: There are many questions having Firehose and Stream. Need to know them in detail to answer. Thanks for the explanation
Comment: Stream is used if you want real time results , but with firehose , you generally use the data at a later point of time by storing it somewhere. Hence if you see "REAL TIME" the answer is most probably Kinesis Data Streams.
Comment: Sorry but I still can't see how Kinesis Data Stream is 'scalable', since you have to provision the quantity of shards in advance?
Comment: "easily stream data at any scale" This is a description of Kinesis Data Stream. I think you can configure its quantity but still not provision and manage scalability by yourself.
Comment: The answer is C, because Firehose does not suppport DynamoDB and another key word is "data" Kinesis Data Streams is the correct choice. Pay attention to key words. AWS likes to trick you up to make sure you know the services.
Comment: One of the tricky phrases is 'near-real-time solutions' because it points to the fact that every time a write is made to a database, it incurs a delay, and then retrieving it with an API call adds another latency. With Kinesis Data Streams, that process is optimized because the intermediary that gives you the ability to write to DynamoDB also provides that data to other services due to the retention period of Kinesis Data Streams.
Comment: Ans C. High level difference between the Kinesis and DynamoDB: Kinesis Streams allows production/ consumption of large volumes of data (web data, logs, etc); DynamoDB Streams is a feature local to DynamoDB to track the granular changes to DynamoDB table items. (Note also: data latency for Firehose is 60 seconds or higher; Streams is for custom processing and has sub-second processing latency).
Comment: Q: What is a destination in Firehose? A destination is the data store where your data will be delivered. Firehose currently supports Amazon S3, Amazon Redshift, Amazon OpenSearch Service, Splunk, Datadog, NewRelic, Dynatrace, Sumo Logic, LogicMonitor, MongoDB, and HTTP End Point as destinations. https://aws.amazon.com/firehose/faqs/
Comment: with multiple consumers and on the fly modification, it seems like the most logical choice
Comment: I chose B. The "near real time" is very specific to Kinesis firehose which is a better option anyway. The rest of the answer makes sense too. C is wrong : "sensitive data removed by Lambda & then store transaction data in DynamoDB" , while it continues to say other applications are accessing the transaction data from kinesis Data stream !!
Comment: need to know.. 1) Lambda Integration 2) Difference between Real time(Kinesis Data Stream) vs Near Real time(Kinesis Fire House) 3) Firehouse can't target DynamoDB
Comment: i think c are bad too, because it isn't near real time.
Comment: A: DynamoDB streams are logs, not fit for real-time sharing. B: S3 is not document database, it's BLOB D: S3 and files are not database C: Kinesis + Lambda + DynamoDB is high performance, low latency scalable solution.
Comment: Answer-C
Comment: Data Stream can handle near-real-time and is able to store to DynamoDB
Comment: Kinesis Data Streams stores data for later processing by applications , key difference with Firehose which delivers data directly to AWS services.
Comment: Correct answer is C. As some commented already, 'near-real-time' could make you think abut Firehose but its consumers are 3rd-party partners destinations, Amazon S3, Amazon Redshift, Amazon OpenSearch and HTTP endpoint so DynamoDB can't be used in this scenario.
Comment: C is the best solution for the following reasons: 1. Real-time Data Stream: To share millions of financial transactions with other apps, you need to be able to ingest data in real-time, which is made possible by Amazon Kinesis Data Streams. 2. Data Transformation: You can cleanse and eliminate sensitive data from transactions before storing them in Amazon DynamoDB by utilizing AWS Lambda with Kinesis Data Streams. This takes care of the requirement to handle sensitive data with care. 3. Scalability: DynamoDB and Amazon Kinesis are both extremely scalable technologies that can manage enormous data volumes and adjust to the workload.
Comment: C is the best solution for the following reasons: 1. Real-time Data Stream: To share millions of financial transactions with other apps, you need to be able to ingest data in real-time, which is made possible by Amazon Kinesis Data Streams. 2. Data Transformation: You can cleanse and eliminate sensitive data from transactions before storing them in Amazon DynamoDB by utilizing AWS Lambda with Kinesis Data Streams. This takes care of the requirement to handle sensitive data with care. 3. Scalability: DynamoDB and Amazon Kinesis are both extremely scalable technologies that can manage enormous data volumes and adjust to the workload. 4. Low-Latency retrieval: Applications requiring real-time data can benefit from low-latency retrieval, which is ensured by storing the processed data in DynamoDB.
Comment: Choices A, B, and D are limited in certain ways: • Real-time data streaming is not provided by Option A (DynamoDB with Streams); additional components would need to be implemented in order to handle data in real-time. • Kinesis Data Firehose, Option B, lacks the real-time processing capabilities of Kinesis Data Streams and is primarily used for data distribution to destinations like as S3. • For near-real-time use cases, Option D (Batch processing with S3) is not the best choice. It adds latency and overhead associated with batch processing, which is incompatible with the need for real-time data sharing. Using the advantages of Lambda, DynamoDB, and Kinesis Data Streams, Option C offers a scalable, real-time, and effective solution for the given use case.
Comment: I picked B. We need to understand how Kinesis Data Warehouse works to answer this question right.
Comment: firehose can not send data to dynamoDB
Comment: CloudTrail - Track user activity and API call history. Config - Assess, audits, and evaluates the configuration and relationships of tag resources. Therefore, the answer is B
Comment: Config = Governance, auditing of AWS resource CloudTrail = API call tracking B is correct
Comment: Answer-B
Comment: Correct Answer- Option B. Here's why AWS Config for Configuration Changes: AWS Config is a service that tracks changes to resource configurations over time. It provides a history of configuration changes to your AWS resources and helps with compliance and auditing by allowing you to assess how resource configurations have changed over time. AWS CloudTrail for API Calls: AWS CloudTrail is designed specifically for recording API calls made to AWS resources. It captures detailed information about who made each API call, the actions taken, and the resources affected. This is essential for auditing and security purposes.
Comment: Correct Answer- Option B. Here's why AWS Config for Configuration Changes: AWS Config is a service that tracks changes to resource configurations over time. It provides a history of configuration changes to your AWS resources and helps with compliance and auditing by allowing you to assess how resource configurations have changed over time. AWS CloudTrail for API Calls: AWS CloudTrail is designed specifically for recording API calls made to AWS resources. It captures detailed information about who made each API call, the actions taken, and the resources affected. This is essential for auditing and security purposes. While Amazon CloudWatch can be used to monitor and gather metrics, it is not designed for recording API calls or tracking configuration changes. AWS Config and AWS CloudTrail are purpose-built for these specific tasks and are the best services to use for the described requirements.
Comment: Although tracking configuration changes and recording API calls are not intended uses for Amazon CloudWatch, it can be utilized for monitoring and collecting data. AWS CloudTrail and AWS Config are purpose-built for these specific tasks and are the best services to use for the described requirements.
Comment: CloudWatch is a monitoring service for AWS resources and applications. CloudTrail is a web service that records API activity in your AWS account.
Comment: CONFIG - AWS CONFIG RECORD API CALLS - CLOUDTRAIL
Comment: CloudWatch is mainly uesd to monitor AWS services with metrics, not recoding actions inside the AWS environments. It can also monitor CloudTrail logged events. For recording API calls it requires CloudTrail.
Comment: Keyword "Amazon CloudWatch" is not for this case, remove C and D. Use AWS Config first to track configuration changes, Second is AWS CloudTrai to record API calls. (Answer B, and correct answer). Answer A is reversed order of B, and not accepted.
Comment: Option B is the right answer for this.
Comment: B is the answer with no doubts
Comment: config => AWS config record API calls => AWS CloudTrail
Comment: To meet the requirement of tracking configuration changes on AWS resources and recording a history of API calls, a solutions architect should recommend option B: Use AWS Config to track configuration changes and AWS CloudTrail to record API calls. Option A (using CloudTrail to track configuration changes and Config to record API calls) is incorrect because CloudTrail is specifically designed to capture API call history, while Config is designed for tracking configuration changes. Option C (using Config to track configuration changes and CloudWatch to record API calls) is not the recommended approach. While CloudWatch can be used for monitoring and logging, it does not provide the same level of detail and compliance tracking as CloudTrail for recording API calls. Option D (using CloudTrail to track configuration changes and CloudWatch to record API calls) is not the optimal choice because CloudTrail is the appropriate service for tracking configuration changes, while CloudWatch is not specifically designed for recording API call history.
Comment: Option B meets ruirements.
Comment: AWS Config is a fully managed service that allows the company to assess, audit, and evaluate the configurations of its AWS resources. It provides a detailed inventory of the resources in use and tracks changes to resource configurations. AWS Config can detect configuration changes and alert the company when changes occur. It also provides a historical view of changes, which is essential for compliance and governance purposes. AWS CloudTrail is a fully managed service that provides a detailed history of API calls made to the company's AWS resources. It records all API activity in the AWS account, including who made the API call, when the call was made, and what resources were affected by the call. This information is critical for security and auditing purposes, as it allows the company to investigate any suspicious activity that might occur on its AWS resources.
Comment: AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. It provides a history of configuration changes made to your resources and can be used to track changes made to your resources over time. AWS CloudTrail is a service that enables you to record API calls made to your AWS resources. It provides a history of API calls made to your resources, including the identity of the caller, the time of the call, the source of the call, and the response element returned by the service.
Comment: Answer is D C is incorrect because question says Third party DNS and route 53 is AWS proprietary
Comment: Right answer, wrong explanation. You can use Route 53 with a custom domain.. it's all about the "large-scale DDOS attack".
Comment: AWS Shield Advanced provides expanded DDoS attack protection for your Amazon EC2 instances, Elastic Load Balancing load balancers, CloudFront distributions, Route 53 hosted zones, and AWS Global Accelerator standard accelerators.
Comment: I´d agree as Shield Advanced is the only tier that can protect EC2 which is not possible in Standard.
Comment: Answer is D
Comment: Ans D. Shield (Advanced) is built for DDoS and can interface to ELB
Comment: A: GuardDuty is not for this, mostly for account monitoring for suspicious activity B: Inspector is for OS vulnerabilities C: Shield with R53 is not going to protect against DDoS D: Shield Advanced is build for DDoS protection
Comment: Forgot to mention, C won't work because a 3rd party DNS is used and R53 is not part of the setup
Comment: Prevent large scale DDOS attack = AWS Shield Advanced
Comment: Answer-D
Comment: - In addition to the network and transport layer protections that come with Standard, Shield Advanced provides additional detection and mitigation against large and sophisticated DDoS attacks, near real-time visibility into attacks, and integration with AWS WAF, a web application firewall. https://aws.amazon.com/shield/features/#:~:text=In%20addition%20to%20the%20network,WAF%2C%20a%20web%20application%20firewall.
Comment: This one got me to be honest
Comment: Option A is incorrect because Amazon GuardDuty is a threat detection service that focuses on identifying malicious activity and unauthorized behavior within AWS accounts. While it is useful for detecting various security threats, it does not specifically address large-scale DDoS attacks. Option B is also incorrect because Amazon Inspector is a vulnerability assessment service that helps identify security issues and vulnerabilities within EC2. It does not directly protect against DDoS attacks. Option C is not the optimal choice because AWS Shield provides basic DDoS protection for resources such as Elastic IP addresses, CloudFront, and Route53 hosted zones. However, it
Comment: does not provide the advanced capabilities and assistance offered by AWS Shield Advanced, which is better suited for protecting against large-scale DDoS attacks. Therefore, option D with AWS Shield Advanced and assigning the ELB to it is the recommended solution to detect and protect against large-scale DDoS attacks in the architecture described.
Comment: D, but can be tricky, the third party negates Route53
Comment: Answer D. Learn section on AWS Advanced Shield on aws.Amazon.com to help you understand this. It helped me.
Comment: answer is D
Comment: DDos = AWS Shield
Comment: large-scale DDos leads to advanced instead of standard AWS Shield.
Comment: Keyword "large-scale DDoS attacks" , "Amazon EC2", "VPC", "ELB", "3rd service used for DNS". Amazon GuardDuty https://aws.amazon.com/guardduty/ Intelligent threat detection. AWS Shield https://aws.amazon.com/shield/ Automatically detect and mitigate sophisticated network-level DDoS. AWS Shield Advanced with ELB https://aws.amazon.com/about-aws/whats-new/2022/04/aws-shield-application-balancer-automatic-ddos-mitigation/ . Choose D.
Comment: Option D is the right answer for this.
Comment: KMS Multi-region keys are required https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html
Comment: I'd say D because multi-region keys can be used with server side encryption as well. "Multi-Region keys are supported in the AWS KMS console, the AWS KMS API, the AWS Encryption SDK, Amazon DynamoDB Encryption Client, and Amazon S3 Encryption Client. AWS services also let you configure multi-Region keys for server-side encryption in case you want the same key to protect data that needs both server-side and client-side encryption." https://aws.amazon.com/blogs/security/encrypt-global-data-client-side-with-aws-kms-multi-region-keys/
Comment: It's not correct because the question asks for server side encryption, not client side (before the objects reach the bucket).
Comment: Note, The question did not ask for server side encryption, It stated Customer manages encryption. So reason why Customer side encryption makes the solution much easier and applicable. Hence B as an answer
Comment: It says encrypt all data and the data originates from the application. Making it B
Comment: Absoutely D is the right one because s3 kms multi region as an individual key so you must first decrypt in source bucket and then re-encrypt in target bucket
Comment: Note, The question did not ask for server side encryption, It stated Customer manages encryption. So reason why Customer side encryption makes the solution much easier and applicable. Hence B as an answer
Comment: Answer is D : This option aligns with the requirement to use a customer-managed KMS key for encryption. It also ensures that the same KMS key is used for encryption and decryption across both AWS Regions, as required. By using SSE-KMS, you can ensure that encryption keys are managed by AWS KMS, providing greater control and security over the encryption process. Configuring replication between the S3 buckets ensures that data is synchronized across both regions. This approach minimizes operational overhead while meeting the specified requirements.
Comment: Note, The question did not ask for server side encryption, It stated Customer manages encryption. So reason why Customer side encryption makes the solution much easier and applicable. Hence B as an answer
Comment: The SAME key would exist in both regions
Comment: KMS multi-region keys are typically used when you need to enable cross-Region replication of encrypted data
Comment: Cannot be A - question says customer managed key Cannot B - client side encryption is operational overhead Cannot C -as it says SSE-S3 instead of customer managed so the answer is D though it required one time setup of keys
Comment: How does client side encryption increase OPERATIONAL overhead? Do you think every connected client is sitting there with gpg cli, decrypting/encrypting every packet that comes in/out? No, it's done via SDK -> https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html The correct answer is B because that's the only way to actually get the same key across multiple regions with minimal operational overhead
Comment: "The data in both S3 buckets must be encrypted and decrypted with the same KMS key" Client side encryption means that key is generated in from the cient without storing that in the KMS...
Comment: fun joke, if u dont do encryption on client side, where else could it be?
Comment: It could be server side. For client side, the application need to finish the encryption and decryption by itself. So S3 object encryption on the server side is less operational overhead. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html But for option B, the major issue is if you create KMS keys in 2 regions, they can not be the same.
Comment: Sorry for the typo, I mean option D.
Comment: Kindly point at where server-side encryption support multi-region. It is only mention on the aws blog that client-side support multi-region.
Comment: The data in both S3 buckets must be encrypted and decrypted with the same KMS key. AWS KMS supports multi-Region keys, which are AWS KMS keys in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions. "as though" means it's different. So I agree with B
Comment: key change across regions unless you use multi-Region keys
Comment: B includes replicating the data in the S3 buckets, which is not mentioned anywhere in the stem. It says that you need to store data in two buckets, not that you need to replicate content between buckets.
Comment: All the choices involve replication between the buckets.
Comment: Can't you guys see "it must be stored in KMS"?
Comment: The Correct answer is D. The key requirement is: "The company must use an AWS Key Management Service (AWS KMS) customer managed key to encrypt all data that is stored in the S3 buckets." KMS doesn't work for client side encryption!!!
Comment: D is correct answer.
Comment: Lets stick with B
Comment: Customer managed key
Comment: Ans B - multi-region keys
Comment: SSE-S3 uses Amazon S3-managed keys, while SSE-KMS uses customer-managed keys (CMKs) in AWS KMS.
Comment: It is D Create a customer managed KMS key in AWS KMS. Configure your Amazon S3 buckets to use this CMK for server-side encryption (SSE-KMS). During data uploads, specify the CMK as the encryption key using the --sse-kms-key-id parameter. This ensures consistent encryption and decryption across both S3 buckets in different regions. You'll have full control over the key, including rotation, access controls, and cross-account access. https://repost.aws/knowledge-center/s3-object-encryption-keys
Comment: I think the answer was all stated clear in the question per sya. " The data and the key must be stored in each of the two Regions." make it really clear it's either C or D. Since the customer "must use AWS kMS customer managed key to encrypt all data...", the answer should be D.
Comment: https://aws.amazon.com/getting-started/hands-on/replicate-data-using-amazon-s3-replication/ https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-config-for-kms-objects.html Basically, from two sources above, none mention to use KMS Multi Region (Option B), and client-side encryption. Option C is not really valid because SSE-S3 is AWS managed not customer managed. Option D is the most logical and straightforward solution, you can create customer managed SSE-KMS.
Comment: D support Multi region key, use aws KMS (less overhead)
Comment: B for sure
Comment: B is correct because we should use multi-region key in this case.
Comment: going for D because the question says it needs a customer managed KMS key which equals SSE-KMS
Comment: B also have SSE- KMS
Comment: B is correct
Comment: How can Session Manager benefit my organization? Ans: No open inbound ports and no need to manage bastion hosts or SSH keys https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
Comment: Do you know what from the question is it Windows or Linux EC2. I think not so how you want to do SSH session for Windows? Answer is C
Comment: Session Manager provides support for Windows, Linux, and macOS from a single tool
Comment: session manager works with linux, windows, and mac too
Comment: "Cross-platform support for Windows, Linux, and macOS" https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
Comment: Answer is B
Comment: Session Manager provides secure and auditable node management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.
Comment: A: Serial console is for device direct connection to peripherals and monitor boot etc. C: Workable solution but a lot of overhead D: Too much overhead for everyone B: Managed product for this purpose so least overhead. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
Comment: Answer-B
Comment: I go with option B. Here's why--- IAM Roles: Without SSH keys or shared passwords, securely provide access to EC2 instances and AWS services.
Comment: Without requiring direct SSH connection, securely access and control EC2 instances with AWS Systems Manager Session Manager. Least Operational Overhead: An effective and fully managed method of managing instances. Well-Architected Framework: Complies with performance, security, and reliability best practices from AWS. Cons of alternative options: Option A: The automation and flexibility required for secure administration at scale are not provided by using the EC2 serial terminal directly. Option C: There is more operational overhead and complexity when a bastion host is deployed. Option D: For secure instance administration, setting up an AWS Site-to-Site VPN connection is too difficult and not the optimal approach. In conclusion, Option B is suggested as the best option given the given circumstances.
Comment: This solution meets all of the requirements with the LEAST operational overhead. It is repeatable, uses native AWS services, and follows the AWS Well-Architected Framework. Repeatable: The process of attaching an IAM role to an EC2 instance and using Systems Manager Session Manager to establish a remote SSH session is repeatable. This can be easily automated, so that new instances can be provisioned and administrators can connect to them securely without any manual intervention.
Comment: With AWS Systems Manager Session Manager, you can manage your Amazon Elastic Compute Cloud (Amazon EC2) instances, edge devices, on-premises servers, and virtual machines (VMs). You can use either an interactive one-click browser-based shell or the AWS Command Line Interface (AWS CLI). It provides secure and auditable node management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html#:~:text=RSS-,Session%20Manager,-is%20a%20fully
Comment: Keyword "access and administer the instances remotely and securely" See "AWS Systems Manager Session Manager at " https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html .
Comment: Option B is the right answer for this.
Comment: +Centralized access control to managed nodes using IAM policies +No open inbound ports and no need to manage bastion hosts or SSH keys +Cross-platform support for Windows, Linux, and macOS
Comment: Option A provides direct access to the terminal interface of each instance, but it may not be practical for administration purposes and can be cumbersome to manage, especially for multiple instances. Option C adds operational overhead and introduces additional infrastructure that needs to be managed, monitored, and secured. It also requires SSH key management and maintenance. Option D is complex and may not be necessary for remote administration. It also requires administrators to connect from their local on-premises machines, which adds complexity and potential security risks. Therefore, option B is the recommended solution as it provides secure, auditable, and repeatable remote access using IAM roles and AWS Systems Manager Session Manager, with minimal operational overhead.
Comment: The choice for me is the option B.
Comment: B is correct and has the least overhead.
Comment: AWS Systems Manager Session Manager is a fully managed service that provides secure and auditable instance management without the need for bastion hosts, VPNs, or SSH keys. It provides secure and auditable access to EC2 instances and eliminates the need for managing and securing SSH keys.
Comment: I selected B) as "open inbound ports, maintain bastion hosts, or manage SSH keys" https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html However Session Manager comes with pretty robust list of prerequisites to put in place (SSM Agent and connectivity to SSM endpoints). On the other side A) come with basically no prerequisites, but it is only for Linux and we do not have info about OSs, so we should assume Windows as well.
Comment: The keyword that makes option B follows the AWS Well-Architected Framework is "IAM role." IAM roles provide fine-grained access control and are a recommended best practice in the AWS Well-Architected Framework. By attaching the appropriate IAM role to each instance and using AWS Systems Manager Session Manager to establish a remote SSH session, the solution is using IAM roles to control access and follows a recommended best practice.
Comment: Option A (replicating the S3 bucket to all AWS Regions) can be costly and complex, requiring replication of data across multiple Regions and managing synchronization. It may not provide a significant latency improvement compared to the CloudFront solution. Option B (provisioning accelerators in AWS Global Accelerator) can be more expensive as it adds an extra layer of infrastructure (accelerators) and requires associating IP addresses with the S3 bucket. CloudFront already includes global edge locations and provides similar acceleration capabilities. Option D (enabling S3 Transfer Acceleration) can help improve upload speed to the S3 bucket but may not have a significant impact on reducing latency for website visitors. Therefore, option C is the most cost-effective solution as it leverages CloudFront's caching and global distribution capabilities to decrease latency and improve website performance.
Comment: Answer is C
Comment: Some of these questions seem too easy for SAA. These seem like Cloud Practitioner questions...
Comment: Cloudfront is a lovely and affordable CDN for static content.
Comment: S3 static website so CloudFront is the best CDN solution for low cost and low latency A: Very expensive way of doing this B: Makes no sense D: Transfer Acc is for upload boosting C: CloudFront literally solves this problem
Comment: Answer-C
Comment: Option A (replicating the S3 bucket to all AWS Regions) can be costly and complex, requiring replication of data across multiple Regions and managing synchronization. It may not provide a significant latency improvement compared to the CloudFront solution. Option B (provisioning accelerators in AWS Global Accelerator) can be more expensive as it adds an extra layer of infrastructure (accelerators) and requires associating IP addresses with the S3 bucket. CloudFront already includes global edge locations and provides similar acceleration capabilities. Option D (enabling S3 Transfer Acceleration) can help improve upload speed to the S3 bucket but may not have a significant impact on reducing latency for website visitors. Therefore, option C is the most cost-effective solution as it leverages CloudFront's caching and global distribution capabilities to decrease latency and improve website performance.
Comment: Amazon CloudFront is a content delivery network (CDN) service that distributes content globally to reduce latency. By setting up a CloudFront distribution in front of the S3 bucket hosting the static website, you can take advantage of its edge locations around the world to deliver content from the nearest location to the users, reducing the latency they experience. CloudFront automatically caches and replicates content to its edge locations, resulting in faster delivery and lower latency for users worldwide. This solution is highly effective in optimizing performance while keeping costs under control because CloudFront charges are based on actual data transfer and requests, and the pay-as-you-go pricing model ensures that you only pay for what you use.
Comment: Keywords: Global, Reduce latency, S3, Static Website, Cost effective = Amazon CloudFront
Comment: Keyword "Amazon CloudFront" (C).
Comment: Option C is the right answer for this.
Comment: Option C is the right answer for this.
Comment: key words: -around the world -decrease latency -most cost-effective answer is C
Comment: C is the most cost effective.
Comment: Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations around the world, providing low latency and high transfer speeds to users accessing the content. Adding a CloudFront distribution in front of the S3 bucket will cache the static website's content at edge locations around the world, decreasing latency for users accessing the website. This solution is also cost-effective as it only charges for the data transfer and requests made by users accessing the content from the CloudFront edge locations. Additionally, this solution provides scalability and reliability benefits as CloudFront can automatically scale to handle increased demand and provide high availability for the website.
Comment: Cloud front
Comment: Amazon CloudFront is a content delivery network (CDN) that speeds up the delivery of static and dynamic web content, such as HTML, CSS, JavaScript, and images. It does this by placing cache servers in locations around the world, which store copies of the content and serve it to users from the location that is nearest to them.
Comment: A: Made for high levels of I/O opps for consistent, predictable performance. B: Can improve performance of insert opps, but it's a storage performance rather than processing power problem C: for moderate CPU usage D: for scale read-only replicas and doesn't improve performance of insert opps on the primary DB instance
Comment: Option B (changing the DB instance to a memory optimized instance class) focuses on improving memory capacity but may not directly address the storage performance issue. Option C (changing the DB instance to a burstable performance instance class) is suitable for workloads with varying usage patterns and burstable performance needs, but it may not provide consistent and predictable performance for heavy write workloads. Option D (enabling Multi-AZ RDS read replicas with MySQL native asynchronous replication) is a solution for high availability and read scaling but does not directly address the storage performance issue. Therefore, option A is the most appropriate solution to address the performance issue by leveraging Provisioned IOPS SSD storage type, which provides consistent and predictable I/O performance for the Amazon RDS for MySQL database.
Comment: Ans A, as per stephyfresh13: "Provisioned IOPS SSD: This storage type is designed to deliver fast, predictable, and consistent I/O performance, which is crucial for databases with high transaction rates and frequent updates. It allows you to provision a specific level of IOPS to meet the performance requirements of your workload."
Comment: A. Change the storage type to Provisioned IOPS SSD. Here's why: Provisioned IOPS SSD: This storage type is designed to deliver fast, predictable, and consistent I/O performance, which is crucial for databases with high transaction rates and frequent updates. It allows you to provision a specific level of IOPS to meet the performance requirements of your workload. Current Issue: The problem with insert operations taking 10 seconds or longer indicates that the current General Purpose SSD storage is not providing sufficient IOPS for the workload. Provisioned IOPS SSD can significantly improve storage performance and reduce latency for database operations.
Comment: B is the answer, if the company decided that storage is the problem then an IOPS SSD (storage) is the solution and not a memory optimiser.
Comment: A. IOPS is about increasing the number of input connections so you can handle more requests. Which may not be the issue. B. Having a memory optimized class provides more RAM to execute the queries which take upto 10 secs to complete. More RAM means they can execute faster. C and D are distractors. They deal with high availability and timely scalability which are not issues here.
Comment: Database storage is issue so BD is irrelevant C is for performance boost (CPU) which won't help with storage issues A Fix the storage issue
Comment: Answer-A
Comment: Do not misconsider "database storage performance is the problem". I beleive the correct asnwer is B Due too the fact that Mmemory Optimized EC2 instance family is designed for DB servers perf.
Comment: But the stem clearly says that storage performance, NOT memory performance, is the problem. More memory won't increase storage performance.
Comment: A is correct answer because it is talking about storage and transaction speed is slow due to it, should change to iops storage instead.
Comment: A: Made for high levels of I/O opps for consistent, predictable performance. B: Can improve performance of insert opps, but it's a storage performance rather than processing power problem C: for moderate CPU usage D: for scale read-only replicas and doesn't improve performance of insert opps on the primary DB instance
Comment: Copy-paste from pazabal's answer...
Comment: I go with option A. Using Amazon Provisioned IOPS (PIOPS) SSD storage is the best way to solve the performance issue of insert operations taking 10 seconds or longer on an Amazon RDS for MySQL database table with more than 10 million rows and 2 TB of General Purpose SSD storage. A high-performance storage solution with reliable throughput and minimal latency is PIOPS SSD storage. Workloads like insert operations, which demand high I/O performance, are ideally suited for it.
Comment: Key: database storage performance is the problem.
Comment: Option A is answer - A. Change the storage type to Provisioned IOPS SSD. The company's issue is related to storage performance, specifically with insert operations. This suggests that the I/O operations are the bottleneck. Provisioned IOPS SSD storage type is designed to handle the kind of workload the company is experiencing and should help improve the performance of insert operations.
Comment: "The company has determined that the database storage performance is the problem." This is the key statement in the question. Otherwise I would have selected B but this statement here makes A correct.
Comment: yeah "A" is correct is the most suitable option for this scenario, because you need to improve the speed of the reading and writing of the storage system.
Comment: The best solution would be to change the storage type to Provisioned IOPS SSD. This allows you to specify a higher level of IOPS provisioned for your workload's needs.Therefore, switching to Provisioned IOPS SSD storage is the most direct way to resolve the storage performance bottleneck causing the slow insert times. The ability to provision high IOPS makes it the best solution for high throughput transactional workloads like this one.
Comment: Definitely A, it's the most operationally efficient compared to D, which requires a lot of code and infrastructure to maintain. A is mostly managed (firehose is fully managed and S3 lifecycles are also managed)
Comment: what about the 30 days minimum requirement to transition to S3 glacier?
Comment: GLACIER IS 7 DAYS REQUIREMENT NOT 30
Comment: You can directly migrate from S3 standard to glacier without waiting https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: the current article doesn't enable the current option, minimum days are 30
Comment: No , It's not correct , We can change the storage class in day 0 also using lifecycle policy , I implemented in my project, 30 days is just an example.
Comment: This constraint is related to moving from Standard to IA/IA-One Zone only. Nothing to do with Glacier
Comment: Only A makes sense operationally. If you think D, just consider what is needed to move the message from SQS to S3... you are polling daily 14 TB to take out 1 TB... that's no operationally efficient at all.
Comment: I understand A is the most operationally efficient option of all but I can't wrap my head around the fact that objects must have a minimum of 30 days before they can transition or expire from Amazon S3. This means that for the first 30 days after an item is created, you cannot transition or remove it. So, how option A can be the best fit?
Comment: The same 30-day minimum applies when you specify a transition from S3 Standard-IA storage to S3 One Zone-IA. https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: BCD: Additional infra which company doesn't want A: Firehose for ingestion and delivery to S3. Lifecycle for managing archive. Fully managed and operationally easy solution
Comment: Answer-A
Comment: so many words...
Comment: That was an easy A. Kinesis Firehose can load data directly to S3 which makes it the most operationally efficient
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: Key: MOST operationally efficient solution
Comment: "A" is simply correct because kinesis firehouse is made for this, SQS standard is not going to support 500 million alerts 2KB each (1 TB) this service is made for requests that are lighter.
Comment: I picked A. Appeared to be right answer.
Comment: Should be A
Comment: The MOST operationally efficient option is A.
Comment: Keyword "Amazon S3 Glacier" (A).
Comment: Option A is the right answer for this.
Comment: B suggests launching EC2 instances to ingest and store the alerts, which introduces additional infrastructure management overhead and may not be as cost-effective and scalable as using managed services like Kinesis Data Firehose and S3. C involves delivering the alerts to an Amazon OpenSearch Service cluster and manually managing snapshots and data deletion. This introduces additional complexity and manual overhead compared to the simpler solution of using Kinesis Data Firehose and S3. D suggests using SQS to ingest the alerts, but it does not provide the same level of data persistence and durability as storing the alerts directly in S3. Additionally, it requires manual processing and copying of messages to S3, which adds operational complexity. Therefore, A provides the most operationally efficient solution that meets the company's requirements by leveraging Kinesis Data Firehose to ingest the alerts, storing them in an S3 bucket, and using an S3 Lifecycle configuration to transition data to S3 Glacier for long-term archival, all without the need for managing additional infrastructure.
Comment: Focus on keywords: Amazon Kinesis Data Firehose delivery stream to ingest the alerts. S3 Lifecycle configuration to transition data to Amazon S3 Glacier after 14 days.
Comment: This question just screams AppFlow (SaaS integration) https://aws.amazon.com/appflow/
Comment: configuring Auto-Scaling also takes time when compared to AppFlow, in AWS's words "in just a few clicks" > Amazon AppFlow is a fully managed integration service that enables you to securely transfer data between Software-as-a-Service (SaaS) applications like Salesforce, SAP, Zendesk, Slack, and ServiceNow, and AWS services like Amazon S3 and Amazon Redshift, in just a few clicks
Comment: It says "LEAST operational overhead" (ie do it in a way it's the less work for me). If you know a little Amazon AppFlow (see the some videos) you'll see you'll need time to configure and test it, and at the end cope with the errors during the extraction and load the info to the target. The customer in the example ALREADY has some EC2 that do the work, the only problem is the performance, that WILL be improved scaling out and adding a queue (SNS) to decouple the work of notify the user. The operational load of doing this is LESS that configuring AppFlow.
Comment: Agreed, I hesitated a long time exactly for this reason. However, the requirement is to improve the performance as much as possible. I cannot guarantee the same performance with EC2 than with managed services. That's why I eventually voted B.
Comment: "Operational overhead" refers to operation of the solution once it's deployed, it's not about setting it up. EC2 instances that retrieve data from A and write it to B are nonsense, that's what cloud services are meant for.
Comment: With AWS, a managed service is "less operational overhead" regardless of the complexity of the setup. AppFlow management is less of a headache when compared to EC2 management so A cannot be correct. EC2 has a setup overhead of OS/Application/Code hooks, security etc. continuous patching/upgrading seems like more than what you'll need to do with SaaS. B is the correct answer.
Comment: B for sure
Comment: direct connect maybe correct answer but we are making too many assumptions regarding direct connect network requirements.
Comment: Has to be appflow because of the SaaS integration
Comment: First i thought it would be A but with more stydy found if its Saas and need to choose between EC2 and aws managed service one should always choose AWS managed service. So AppFlow seems more appropriate here.
Comment: Amazon AppFlow is a fully managed integration service that helps you securely transfer data between software as a service (SaaS) applications such as Salesforce, SAP, Google Analytics, Facebook Ads, and ServiceNow, and AWS services such as Amazon Simple Storage Service (S3) and Amazon Redshift in just a few clicks. https://aws.amazon.com/appflow/
Comment: https://aws.amazon.com/appflow/ "With Amazon AppFlow automate bi-directional data flows between SaaS applications and AWS services in just a few clicks." If you want to pass the exam, choose B, regardless of your personal experience! Always use AWS managed services for "least operational overhead"
Comment: SaaS - AppFlow
Comment: Yea , I think this question is looking for Amazon Appflow.I also feel like it would be easier to set up Autoscaling for the already existing EC2 instances in the short term but then the fact that this software integrates with a lot of SAAS services means using Amazon Appflow will work reduce operational overhead in the long term
Comment: https://docs.aws.amazon.com/appflow/latest/userguide/what-is-appflow.html
Comment: https://aws.amazon.com/appflow/
Comment: B suits the requirement
Comment: The problem with A is you need to add ALB or ELB in front of ASG, and update DNS for your application, so B seems like a better choice.
Comment: This is a tough one. If they were not already using EC2 the answer would for sure be AppFlow (B). The question says "least operational overheard" so I feel like it takes more work to configure AppFlow than it does to create auto scaling in EC2. If I had this question on the test, I would likely go with AppFlow so B
Comment: While option B utilizes managed services and can be a valid approach, it's important to note that Amazon AppFlow is primarily designed for data integration and synchronization between various SaaS applications and AWS services. It may introduce an additional layer of complexity compared to directly handling the uploads with EC2 instances. Ultimately, the choice between Option A and Option B depends on specific factors such as the existing architecture, the nature of data transfers, and any potential advantages offered by using Amazon AppFlow for data integration. If the primary concern is to improve performance for data uploads and user notifications without introducing new services, Option A (Auto Scaling group with S3 event notifications) would likely be the simpler and more operationally efficient choice. However, if data integration between SaaS sources and the S3 bucket is a critical aspect of the application, Option B might be a more suitable approach.
Comment: SaaS Integration = Amazon AppFlow
Comment: Deploying a gateway VPC endpoint for Amazon S3 is the most cost-effective way for the company to avoid Regional data transfer charges. A gateway VPC endpoint is a network gateway that allows communication between instances in a VPC and a service, such as Amazon S3, without requiring an Internet gateway or a NAT device. Data transfer between the VPC and the service through a gateway VPC endpoint is free of charge, while data transfer between the VPC and the Internet through an Internet gateway or NAT device is subject to data transfer charges. By using a gateway VPC endpoint, the company can reduce its data transfer costs by eliminating the need to transfer data through the NAT gateway to access Amazon S3. This option would provide the required connectivity to Amazon S3 and minimize data transfer charges.
Comment: Very good explanation!
Comment: https://aws.amazon.com/blogs/storage/managing-amazon-s3-access-with-vpc-endpoints-and-s3-access-points/
Comment: Precisely
Comment: C for sure
Comment: Ans C - excellent explanation by SilentMilli
Comment: VPC gatwway endpoint is free to use, but only available for S3 and DynamoDB
Comment: Gateway VPC allows direct access to S3 without going through public internet. This is the de-facto way to save cost for S3 to VPC traffic. Correct answer is C
Comment: Avoid regional data transfer charge - VPC endpoint
Comment: https://aws.amazon.com/blogs/storage/managing-amazon-s3-access-with-vpc-endpoints-and-s3-access-points/
Comment: Gateway Endpoint bests suits the requirement
Comment: Answer is C: An S3 VPC endpoint provides a way for an S3 request to be routed through to the Amazon S3 service, without having to connect a subnet to an internet gateway. The S3 VPC endpoint is what's known as a gateway endpoint.
Comment: the EC2 instances are downloading and uploading images to S3, configuring a gateway VPC endpoint will allow them to access S3 without crossing Availability Zones or regions, eliminating regional data transfer charges
Comment: Gateway VPC endpoints provide reliable connectivity to Amazon S3 without requiring an internet gateway or a NAT device for your VPC.
Comment: Option C is the right answer.
Comment: By deploying a gateway VPC endpoint for S3, the company can establish a direct connection between their VPC and S3 without going through the internet gateway or NAT gateway. This enables traffic between the EC2 and S3 to stay within the Amazon network, avoiding Regional data transfer charges. A suggests launching the NAT gateway in each AZ. While this can help with availability and redundancy, it does not address the issue of data transfer charges, as the traffic would still traverse the NAT gateways and incur data transfer fees. B suggests replacing the NAT gateway with a NAT instance. However, this solution still involves transferring data between the instances and S3 through the NAT instance, which would result in data transfer charges. D suggests provisioning an EC2 Dedicated Host to run the EC2. While this can provide dedicated hardware for the instances, it does not directly address the issue of data transfer charges.
Comment: Option C is the answer.
Comment: A gateway VPC endpoint is a fully managed service that allows connectivity from a VPC to AWS services such as S3 without the need for a NAT gateway or a public internet gateway. By deploying a Gateway VPC endpoint for Amazon S3, the company can ensure that all S3 traffic remains within the VPC and does not cross the regional boundary. This eliminates regional data transfer charges and provides a more cost-effective solution for the company.
Comment: C - gateway VPC endpoint.
Comment: 'Regional' data transfer isn't clear but I think we have to assume this means the traffic stays in the region. The two options that seem possible are NAT gateway per AZ vs privatelink gateway endpoints per AZ. privatelink/endpoints do have costs (url below) privatelink endpoint / LB costs look lower than NAT gateway costs privatelink doesn't incur inter-AZ data transfer charges (if in the same region) as NAT gateways do which goes towards the key requirement stated good writeup here : https://www.vantage.sh/blog/nat-gateway-vpc-endpoint-savings https://aws.amazon.com/privatelink/pricing/ https://aws.amazon.com/vpc/pricing/ https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/
Comment: A: VPN also goes through the internet and uses the bandwidth C: daily Snowball transfer is not really a long-term solution when it comes to cost and efficiency D: S3 limits don't change anything here So the answer is B
Comment: Option B (correct). Establish a new AWS Direct Connect connection and direct backup traffic through this new connection. AWS Direct Connect is a network service that allows you to establish a dedicated network connection from your on-premises data center to AWS. This connection bypasses the public Internet and can provide more reliable, lower-latency communication between your on-premises application and Amazon S3. By directing backup traffic through the AWS Direct Connect connection, you can minimize the impact on your internet bandwidth and ensure timely backups to S3.
Comment: Option A (wrong), establishing AWS VPN connections and proxying all traffic through a VPC gateway endpoint, would not necessarily minimize the impact on internet bandwidth as it would still utilize the public Internet to access S3. Option C (wrong), using AWS Snowball devices, would not address the issue of internet bandwidth limitations as the data would still need to be transferred over the Internet to and from the Snowball devices. Option D (wrong), submitting a support ticket to request the removal of S3 service limits, would not address the issue of internet bandwidth limitations and would not ensure timely backups to S3.
Comment: Snowball isn't timely since it takes days after ordering to receive the Snowball devices and days to have it shipped and backed up
Comment: Option C is wrong so is your reason. you do not need internet to load data into Snowball Devices. if you are using snow cone for example, u will connect it to your on-premises device directly for loading and Aws will load it in the cloud. However, it not effective to do that everyday , hence option B is the better choice.
Comment: You're right Option B is the correct answer. I answered Option B as the correct answer above.
Comment: The answer is B
Comment: Direct Connect is the only working solution. A: VPN uses same bandwidth so doesn't solve anything C: Snowball devices are physical devices requiring physical shipment so wrong solution D: There are no S3 service limitations in the account related to this problem
Comment: Option B. AWS Direct Connect link your on-premise instance with VPC, and all traffic will bypass your Internet Service Provider. https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
Comment: Resolve Internet connection problem - Direct Connect
Comment: AWS Direct Connect is a network service that allows you to establish a dedicated network connection from your on-premises data center to AWS. This connection bypasses the public Internet and can provide more reliable, lower-latency communication between your on-premises application and Amazon S3. By directing backup traffic through the AWS Direct Connect connection, you can minimize the impact on your internet bandwidth and ensure timely backups to S3.
Comment: I picked option B, because AWS Direct Connect offers a dedicated, secure, high-performance connection that may circumvent bandwidth restrictions and minimize the impact on internet access, AWS Direct Connect is the ideal choice for backing up data to Amazon S3. Some solutions are not as good because they are not as scalable, reliable, or secure as VPN connections, Snowball devices, or reducing S3 service constraints.
Comment: Key: time sensitive. So snowball does not apply here.
Comment: Right option is C,, In AWS Direct Connect, the network is not fluctuating and provides a consistent experience, while in AWS VPN the VPN is connected with shared and public networks, so the bandwidth and latency fluctuate. Hence direct connect is better choice than virtual connect.
Comment: Typo correction to my my above comment. The right option is B.
Comment: Option B Correct. Reason is that, Direct connect will not use internet. But it will take good amount of time to establish the connectivity.
Comment: AWS Direct Connect is a dedicated network connection between your on-premises network and AWS. This provides a private, high-bandwidth connection that is not subject to the same internet bandwidth limitations as traditional internet connections. This will allow for timely backups to Amazon S3 without impacting internet connectivity for internal users.
Comment: AWS Direct Connect cloud service is the shortest path to your AWS resources. While in transit, your network traffic remains on the AWS global network and never touches the public internet. This reduces the chance of hitting bottlenecks or unexpected increases in latency. https://aws.amazon.com/directconnect/#:~:text=The-,AWS%20Direct%20Connect,-cloud%20service%20is
Comment: Option B is the right answer.
Comment: This is long-term and provides solution for internet speed as well
Comment: AWS Direct Connect provides a dedicated network connection between on-premises and AWS, bypassing public internet. By establishing this connection for backup traffic, company can ensure fast and reliable transfers between their on-premises and S3 without impacting their internet connectivity for internal users. This provides a dedicated and high-speed connection that is well-suited for data transfers and minimizes impact on internet bandwidth limitations. While option A can provide a secure connection, it still utilizes internet bandwidth for data transfer and may not effectively address issue of limited bandwidth. While option C can work for occasional large data transfers, it may not be suitable for frequent backups and can introduce additional operational overhead. D, submitting a support ticket to request removal of S3 service limits, does not address issue of internet bandwidth limitations and is not a relevant solution for given requirements.
Comment: Galleta siempre veo tus comentarios! sos crack!
Comment: Option B meets these requirements.
Comment: The correct solution is AB, as you can see here: https://aws.amazon.com/it/premiumsupport/knowledge-center/s3-audit-deleted-missing-objects/ It states the following: To prevent or mitigate future accidental deletions, consider the following features: Enable versioning to keep historical versions of an object. Enable Cross-Region Replication of objects. Enable MFA delete to require multi-factor authentication (MFA) when deleting an object version.
Comment: but it could be C you could use 's3:deleteobject" permission without specific conditions or restricts only to authorized users. B does the same thing tho but B is mainly used to restrict unauthroized access not deletion. does anyone agree. I think it is A and C or A & B
Comment: Enabling versioning on S3 ensures multiple versions of object are stored in bucket. When object is updated or deleted, new version is created, preserving previous version. Enabling MFA Delete adds additional layer of protection by requiring MFA device to be present when attempting to delete objects. This helps prevent accidental or unauthorized deletions by requiring extra level of authentication. C. Creating a bucket policy on S3 is more focused on defining access control and permissions for bucket and its objects, rather than protecting against accidental deletion. D. Enabling default encryption on S3 ensures that any new objects uploaded to bucket are automatically encrypted. While encryption is important for data security, it does not directly address accidental deletion. E. Creating lifecycle policy for objects in S3 allows for automated management of objects based on predefined rules. While this can help with data retention and storage cost optimization, it does not directly protect against accidental deletion.
Comment: but it could be C you could use 's3:deleteobject" permission without specific conditions or restricts only to authorized users. B does the same thing tho but B is mainly used to restrict unauthroized access not deletion. does anyone agree. I think it is A and C or A & B
Comment: To protect critical data in an Amazon S3 bucket from accidental deletion, a solutions architect should take the following steps: Enable versioning on the S3 bucket: This allows you to recover objects that are accidentally deleted or overwritten by keeping multiple versions of an object. Enable MFA Delete on the S3 bucket: This adds an extra layer of security by requiring multi-factor authentication (MFA) for delete operations, which helps prevent accidental or unauthorized deletions
Comment: Ans A,B - as per 'kwabsAA' 2 months ago "To protect data from accidental deletion, the correct answers are B and D. Versioning does not prevent accidental deletion; it only allows for recovery after the fact. Multi-Factor Authentication (MFA) helps prevent accidental deletion by requiring an additional confirmation step before deletion, making it deliberate rather than accidental. Option D, which involves encryption, ensures that only individuals with the encryption keys can read or manipulate the data, thus preventing unauthorized access and manipulation, including deletion."
Comment: encryption will not prevent accidental deletions
Comment: To protect data from accidental deletion, the correct answers are B and D. Versioning does not prevent accidental deletion; it only allows for recovery after the fact. Multi-Factor Authentication (MFA) helps prevent accidental deletion by requiring an additional confirmation step before deletion, making it deliberate rather than accidental. Option D, which involves encryption, ensures that only individuals with the encryption keys can read or manipulate the data, thus preventing unauthorized access and manipulation, including deletion.
Comment: you do realised B and D are only to stop unauthroized people from deleting it and if they did delete it would be on purpose to cause issues for a business. it says accidental id say A and C. idk the questions worded poorly dont trust half the answers on here
Comment: but it could be C you could use 's3:deleteobject" permission without specific conditions or restricts only to authorized users. B does the same thing tho but B is mainly used to restrict unauthroized access not deletion. does anyone agree. I think it is A and C or A & B. A allows multiple versions of objects to be stored in the bucket. Even if an object is deleted, its previous versions remain intact and accessible. idk the questions weird i could see how it could be all of them except D & E
Comment: BD. For D, When you encrypt data, an unauthorized user (without the encryption key) cannot manipulate the data (ie. decryption, modifying, deletion).
Comment: AB will be the correct answer.
Comment: This could be done if we enable MFA delete on the bucket but in order to enable this bucket versioning must be done. Hence A and B would be the answer.
Comment: but it could be C you could use 's3:deleteobject" permission without specific conditions or restricts only to authorized users. B does the same thing tho but B is mainly used to restrict unauthroized access not deletion. does anyone agree. I think it is A and C or A & B
Comment: I am getting so confused about what answers I should study. The answers don't match here or in ChatGPT. Can anyone who just took the exam, and passed, point me in the right direction? TIA!
Comment: chatgpt will help you only if you gave correct prompt.
Comment: yea chatgpt said A and C it does make sense. Cause B is mainly used for unauthroized access not deletion. idk this website and certlibrary give some interesting answers makes it hard to know but some questions are difficult
Comment: B: MFA to put an extra step to verify deletion and stop from accidental deletion A: Versioning for recovery of objects that were deleted accidentally even with MFA Remember, the solution is not required to STOP from deletion. It just wants to STOP ACCIDENTAL deletion. CDE offer nothing related to accidental deletion
Comment: Not sure why Answer is BD. I am trying to rationalize it. What I guess could be to address keyword "critical data" where set default encryption is just enhance the security of stored data but does not prevent from deletion. This will be have 2 options A, B for that. B is make sense to ensure user know what to delete on second layer. For option A, it just help you to audit and recovered what was accidentally deleted but does not "prevent" accidentally delete.
Comment: Agree, s3 encryption does not prevent deletion
Comment: Yeah so.. encryption is enabled by default on S3, sooooo why is the answer D. --------- Starting today, Amazon Simple Storage Service (Amazon S3) encrypts all new objects by default. Now, S3 automatically applies server-side encryption (SSE-S3) for each new object, unless you specify a different encryption option.
Comment: What's the correct answers？
Comment: I would say A & C
Comment: Prevent accidental deletion - MFA, Versioning
Comment: MFA will add extra security of deleting item from s3 Versioning will make the data recovering
Comment: A, C, D options are out, since Lambda is fully managed service which provides high availability and scalability by its own Answers are B and E
Comment: There are times you do have to increase lambda memory for improved performance though. But not in this case.
Comment: BE so that the lambda function reads the SQS queue and nothing gets lost
Comment: Create an Amazon Simple Queue Service (Amazon SQS) queue, and subscribe it to the SNS topic: This will decouple the data ingestion process and ensure that messages are not lost if the Lambda function fails to process them immediately Modify the Lambda function to read from an Amazon Simple Queue Service (Amazon SQS) queue: This ensures that the Lambda function can process the messages from the SQS queue, providing a reliable way to handle data ingestion even if there are network issues.
Comment: BE for sure
Comment: BE is correct as SQS ensures the messages are stored in a queue for processing. A: No issue with Lambda availability so this solution is wrong C: No issues with CPU or memory so no value added by this step also D: This is not a provisioning issue so provisioning more Lambda won't solve the re-execution issues. The missed messages will still be lost
Comment: Since network timeout is the issue here, introduce SQS and read from it , that way when network goes down, data still remains in the queue and when connectivity is back, the lambda function can continue from the last data in the queue
Comment: Nice explaination
Comment: explanation*
Comment: the correct combination of actions to ensure that the Lambda function ingests all data in the future is to create an SQS queue and subscribe it to the SNS topic (option B) and modify the Lambda function to read from the SQS queue (option E).
Comment: Key: network connectivity issues
Comment: This one told you the answer in the answer choices. Just add the word THEN between B and E and there ya go.
Comment: B and E , the FAN out model , SQS will help to retrie the work and delayed processing
Comment: B) Create an Amazon Simple Queue Service (Amazon SQS) queue, and subscribe it to the SNS topic. E) Modify the Lambda function to read from an Amazon Simple Queue Service (Amazon SQS) queue.
Comment: BE is most logical answer.
Comment: Option BE is the right answer.
Comment: A. Deploying the Lambda function in multiple Availability Zones improves availability and fault tolerance but does not guarantee ingestion of all data. C. Increasing CPU and memory allocated to the Lambda function may improve its performance but does not address the issue of connectivity failures. D. Increasing provisioned throughput for the Lambda function is not applicable as Lambda functions are automatically scaled by AWS and provisioned throughput is not configurable. Therefore, the correct combination of actions to ensure that the Lambda function ingests all data in the future is to create an SQS queue and subscribe it to the SNS topic (option B) and modify the Lambda function to read from the SQS queue (option E).
Comment: The combination of actions should a solutions architect take to ensure that the Lambda function ingests all data in the future, are by Creating an Amazon Simple Queue Service (Amazon SQS) queue, and subscribe it to the SNS topic, and Modifying the Lambda function to read from an Amazon Simple Queue Service (Amazon SQS) queue
Comment: B. Create an Amazon Simple Queue Service (Amazon SQS) queue, and subscribe it to the SNS topic. This will decouple the ingestion workflow and provide a buffer to temporarily store the data in case of network connectivity issues. E. Modify the Lambda function to read from an Amazon Simple Queue Service (Amazon SQS) queue. This will allow the Lambda function to process the data from the SQS queue at its own pace, decoupling the data ingestion from the data delivery and providing more flexibility and fault tolerance.
Comment: Help Can SQS Queue have multiple consumers so SNS and Lambda can consume at the same time?
Comment: I have a problem with answer B. The question says: "automate remediation". B says that you inform the administrator and he removes the data manually, that's not automating remediation. Very weird, that would mean that D is correct - but it's so much harder to implement.
Comment: The answer is B because it requires the "LEAST development effort". The confusing part is that remediation is NOT automated because the solution alerts the administrators but still requires manual action. Its a bad question.
Comment: B Correct, a bad and selfish question indeed. AWS doesn't care if they actually follow through on the standards they created, they are only interested in us answering the question right . MIND YOU ALL THE OPTIKNS REQUIRE MANUAL COMPLETION OF PROCESS.
Comment: What kind of life cycle policy removes meat ?. Life cycle only removes objects that exceeds programmed time.
Comment: Macie has file size limit and clearly question mentions 200GB filesizes are possible. Lambda is the way to go ..
Comment: You're confusing "files to retrieve samples from" with "files to analyze". Macie can analyze 20 GB files.
Comment: Pay attention to the entire question as in What should a solutions architect do to meet these requirements with the LEAST development effort? That is why Macie is used. Answer is B
Comment: By "automate remediation", I thought it meant to use Amazon Macie to automate discovery on personally identifiable information. https://aws.amazon.com/macie/ - Discover sensitive data across your S3 environment to increase visibility and automated remediation of data security risks.
Comment: Amazon Macie is a data security and data privacy service that uses machine learning (ML) and pattern matching to discover and protect your sensitive data
Comment: Macie automatically detects a large and growing list of sensitive data types, including personally identifiable information (PII) such as names, addresses, and credit card numbers. It also gives you constant visibility of the data security and data privacy of your data stored in Amazon S3
Comment: B is closest, but Macie should trigger Lambda for remediation
Comment: I would have said Ans D because questions states "automate remeditation". That conundrum nicely captured by 'wamy1738' 4 months ago: "The answer is B because it requires the 'LEAST development effort'. The confusing part is that remediation is NOT automated because the solution alerts the administrators but still requires manual action. Its a bad question."
Comment: Can not be D because how can a lambda trigger a life cycle policy to remove PII, this is not practical and life cycle policies does not remove files by an invocationCan not be D because how can a lambda trigger a life cycle policy to remove PII, this is not practical and life cycle policies does not remove files by an invocation
Comment: This is poorly worded - why does option D have "meats" in it?! Amazon Macie cannot handle files larger than 8GB, so it has to be option D.
Comment: This quota applies only to the Amazon Macie console and the Amazon Macie API. There isn't a quota for the number of finding events that Macie publishes to Amazon EventBridge or the number of sensitive data discovery results that Macie creates for each run of a job. reference :https://docs.aws.amazon.com/macie/latest/user/macie-quotas.html
Comment: This question is written incorrectly. D has the word "meat" in it for example. Some of the answers are written incorrectly I think or maybe the question is but the answer is B
Comment: It's B. This is the trickiest question I've seen so far. Here, you _must_ know precisely what these tools do because context clues won't help you. You *have* to read the question carefully; poor reading comprehension will hurt you. If you're successful at both, the answer is obvious. You need to remedy or fix the problem automatically and simply notify an admin. Macie and (Amazon SNS). The answer is B. "Macie detects a potential issue with the security or privacy of your data, such as a bucket that becomes publicly accessible, Macie generates a finding for you to review and remediate as necessary" - https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
Comment: It's B. This is the trickiest question I've seen so far. Here, you _must_ know precisely what these tools do because context clues won't help you. You *have* to read the question carefully; poor reading comprehension will hurt you. If you're successful at both, the answer is obvious. You need to remedy or fix the problem automatically and simply notify an admin. Macie and (Amazon SNS). The answer is B. "Macie detects a potential issue with the security or privacy of your data, such as a bucket that becomes publicly accessible, Macie generates a finding for you to review and remediate as necessary" - https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
Comment: Please note that the question requires a solution that "AUTOMATES REMEDIATION" B states: "trigger a notification to the ADMINISTRATORS TO REMOVE the objects that contain PII" This goes against the "AUTOMATE" requirement
Comment: Macie does the remediation - See my previous comment. "Macie detects a potential issue with the security or privacy of your data, such as a bucket that becomes publicly accessible, Macie generates a finding for you to review and remediate as necessary" - https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
Comment: Option B does not have the 'Automatic remediation' which is a criteria of the solution. So have to go with D, though it is not a perfect solution.
Comment: Also as per the below link it seems Amazon macie can not work on files as big as 200 GB https://docs.aws.amazon.com/macie/latest/user/macie-quotas.html
Comment: I'm going to with D. A is not the answer because Amazon Inspector does not detect PII. B could be except for the "automate remediation". C does not automate remediation. Even with the extra development effort, D is the answer that suits better the question.
Comment: Macie does do remediation https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html Also the question asks for the solution with the LEAST development effort. Maybe its just me, but I would assume creating a custom scanner would take some time to develop.
Comment: Always prefer AWS manages solution, especially when they have a SaaS over custom solution when the ask for "with the LEAST development effort". Anything else doesn't really matter. B is the only choice as Macie is PII detection and SNS is for alerting.
Comment: Auto remediation is a Macie's feature so B is CORRECT https://aws.amazon.com/macie/#:~:text=Discover%20sensitive%20data%20across%20your,remediation%20of%20data%20security%20risks.
Comment: Each time the question asks about PII and security posture of your organization in S3, the option with Macie should be considered. https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
Comment: I am in the consideration B and D. Based on the requirement, it need to detect and notify administrator when PII data uploaded. And with LEAST development effort - option B definite an answer. However, it does not meet the automate remediation which need some extra configuration. I opt for D for the reason meeting 3 points, but development (on coding) could be extra/ also subject to the skillset and experience. Any thought?
Comment: Keywords- Sensitive data, Alert, PII = Macie
Comment: Reserved instances are for long term so on-demand will be the right choice - Answer D
Comment: Confirmed! Reserved instances require a fixed one-year or three-year commitment. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html#capacity-reservations-differences
Comment: ***CORRECT*** Option D. Create an On-Demand Capacity Reservation that specifies the Region and three Availability Zones needed. An On-Demand Capacity Reservation is a type of Amazon EC2 reservation that enables you to create and manage reserved capacity on Amazon EC2. With an On-Demand Capacity Reservation, you can specify the Region and Availability Zones where you want to reserve capacity, and the number of EC2 instances you want to reserve. This allows you to guarantee capacity in specific Availability Zones in a specific Region. ***WRONG*** Option A, purchasing Reserved Instances that specify the Region needed, would not guarantee capacity in specific Availability Zones. Option B, creating an On-Demand Capacity Reservation that specifies the Region needed, would not guarantee capacity in specific Availability Zones. Option C, purchasing Reserved Instances that specify the Region and three Availability Zones needed, would not guarantee capacity in specific Availability Zones as Reserved Instances do not provide capacity reservations.
Comment: Another reason as to why Reserved Instances aren't the solution here is that you have to commit to either a 1 year or 3 year term, not 1 week.
Comment: i always get these wrong
Comment: Picked C for this one and failed. Reserved Instances are reserved for 1-3 years so On-Demand Reservation makes more sense.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html "On-Demand Capacity Reservations enable you to reserve compute capacity for your Amazon EC2 instances in a specific Availability Zone for any duration"
Comment: Just to avoid any confusion, Reserved Instance also guarantee capacity reservation. However, the reason why we don't need Reserved Instances is because they are reserved for a duration of 1 to 3 years with a lock-in contract (no refunds!). The company is only interested in reserved capacity for a week so D is the best solution. https://aws.amazon.com/compare/the-difference-between-on-demand-instances-and-reserved-instances/
Comment: Guarantee capacity on 3 AZ - on demand reservation, specify region & Availability Zone
Comment: ***CORRECT*** Option D. Create an On-Demand Capacity Reservation that specifies the Region and three Availability Zones needed. An On-Demand Capacity Reservation is a type of Amazon EC2 reservation that enables you to create and manage reserved capacity on Amazon EC2. With an On-Demand Capacity Reservation, you can specify the Region and Availability Zones where you want to reserve capacity, and the number of EC2 instances you want to reserve. This allows you to guarantee capacity in specific Availability Zones in a specific Region.
Comment: Reserved Instances have a commitment over a year so those are out. Option B only allows you to specify the Region and not the AZ. Therefore, D is the only solution.
Comment: its B , On-Demand Capacity Reservation allows you to reserve capacity for Amazon EC2 instances in a specific AWS Region, without specifying specific Availability Zones
Comment: D is the correct option to guarantee EC2 capacity in specific Availability Zones for a set timeframe. On-Demand Capacity Reservations allow you to reserve EC2 capacity across specific Availability Zones for any duration. This guarantees you will have access to those resources.
Comment: Option D is the right answer.
Comment: The most appropriate option to guarantee EC2 capacity in three specific Availability Zones in the desired AWS Region for the 1-week event is to create an On-Demand Capacity Reservation that specifies the Region and three Availability Zones (option D). A. Purchasing Reserved Instances that specify the Region needed does not guarantee capacity in specific Availability Zones. B. Creating an On-Demand Capacity Reservation without specifying the Availability Zones would not guarantee capacity in the desired zones. C. Purchasing Reserved Instances that specify the Region and three Availability Zones is not necessary for a short-term event and involves longer-term commitments.
Comment: Reserved instances is for long term On-demand Capacity reservation enables you to choose specific AZ for any duration
Comment: Just for 1 week so D on demand
Comment: I agree that the answer is D because its only needed for a 1 week event. C would be right if it was a re-occurring event for 1 or more years as reserved instances have to be purchased on long term commitments but would satisfy the capacity requirements. https://aws.amazon.com/ec2/pricing/reserved-instances/
Comment: D. Reservations are used for long term. A minimum of 1 - 3 years making it cheaper. Whereas, on demand reservation is where you will always get access to CAPACITY it either be 1 week in advance or 1 month in an AZ but you pay On-Demand price meaning there is no discount.
Comment: Correct answer is On-Demand Capacity Reservation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html
Comment: keyword is "durable" location A and B is ephemeral storage C takes forever so is not HA, that leaves D
Comment: Yes, if you open EFS home page (https://aws.amazon.com/efs/), Amazon state, "Securely and reliably access your files with a fully managed file system designed for 99.999999999 percent (11 9s) durability and up to 99.99 percent (4 9s) of availability."
Comment: Elasticache is in Memory, EFS is for durability
Comment: That's wrong. EFS is highly available.
Comment: Ans D - the clue is its the only option that offers "durable" (Not sure why the author suggests A??)
Comment: Durability is the key differentiator
Comment: If they are in instance store now, would EFS maintain the performance necessary for them? I don't think the performance would be similar.
Comment: The Elasticache option solves both storage and availability issues.
Comment: Cache is not Durable
Comment: D would be correct why would it give me A. :/
Comment: A and B are distractors. D is durable and HA.
Comment: durable location
Comment: Option C, which suggests moving the catalog to Amazon S3 Glacier Deep Archive, is not a suitable choice for an active catalog that requires high availability and quick access. Glacier Deep Archive is designed for long-term archival and may not provide the low-latency access required for a catalog used in a website. Therefore, option D is the most appropriate choice for achieving both high availability and durability for the catalog.
Comment: SEE https://aws.amazon.com/elasticache/faqs/#Redis
Comment: Redis an be made durable, supports failover and multi-AZ deployment, it's effective in catalog use cases. EFS is effective when a shared storage is needed
Comment: A and D, who win?
Comment: EC for Redis: Durability is a consideration, but the primary use case is caching EFS: Durability is a core feature for file-based data
Comment: Amazon EFS (Option D) provides the necessary combination of high availability, durability. See question states that high availabilty with durable location
Comment: Everyone else pretty much covered it but yes the answer is D. EFS- Securely and reliably access your files with a fully managed file system designed for 99.999999999 percent (11 9s) durability and up to 99.99 percent (4 9s) of availability
Comment: I think the answer is B: Users access the files randomly S3 Intelligent-Tiering is the ideal storage class for data with unknown, changing, or unpredictable access patterns, independent of object size or retention period. You can use S3 Intelligent-Tiering as the default storage class for virtually any workload, especially data lakes, data analytics, new applications, and user-generated content. https://aws.amazon.com/fr/s3/storage-classes/intelligent-tiering/
Comment: What about if the file you have not accessed 360 days and intelligent tier moved the file to Glacier and on 364 day you want to access the file instantly ? I think C is right choice
Comment: bro u r forgetting cost effectiveness which is the requirement 1 yr in s3 standard will cost more than s3 intelligent tire.
Comment: It says "S3 Intelligent-Tiering is the ideal storage class for data with unknown, changing, or unpredictable access patterns". However, the statement says access pattern is predictable. It says there is frequent access about 1year.
Comment: Helps to read sometimes
Comment: It syas "... access the files INFREQUENTLY after 1 year"
Comment: it doesnt say predictable, it says files are accessed random. Random = Unpredictable. Answer is B
Comment: Agree, S3 Intelligent-Tiering meets all the requirements. The very important/crucial consideration here to satisfy that all files withing a year are instantly accessible is that the two options "Archive Access" and "Deep Archive Access" are not enabled in the "Archive rule actions" section present in the "Intelligent-Tiering Archive configurations" of the bucket. Those options are not enabled by default so this answer will work.
Comment: Answer is C, why not intelligent Tiering If the Intelligent-Tiering data transitions to Glacier after 180 days instead of 1 year, it would still be a cost-effective solution that meets the requirements. With files stored in Amazon S3 Intelligent-Tiering, the data is automatically moved to the appropriate storage class based on its access patterns. In this case, if the data transitions to Glacier after 180 days, it means that files that are infrequently accessed beyond the initial 180 days will be stored in Glacier, which is a lower-cost storage option compared to S3 Standard.
Comment: The Answer is B. S3 Intelligent-Tiering stores objects in two access tiers: one tier that is optimized for frequent access and another lower-cost tier that is optimized for infrequent access. For a small monthly monitoring and automation fee per object, S3 Intelligent-Tiering monitors access patterns and moves objects that have not been accessed for 30 consecutive days to the infrequent access tier. There are no retrieval fees in S3 Intelligent-Tiering. If an object in the infrequent access tier is accessed later, it is automatically moved back to the frequent access tier. No additional tiering fees apply when objects are moved between access tiers within the S3 Intelligent-Tiering storage class. S3 Intelligent-Tiering is designed for 99.9% availability and 99.999999999% durability, and offers the same low latency and high throughput performance of S3 Standard
Comment: Are you not going to pay for Athena usage?
Comment: With S3 Intelligent-Tiering, you can define rules that determine when objects should be moved from the frequent access tier to the infrequent access tier, or vice versa, within S3 Standard storage classes.
Comment: C involves moving "the files to S3 Glacier Instant Retrieval" which is not cost-effective since "a delay in retrieving older files is acceptable."
Comment: The answer is B
Comment: cost effective to retrieve the file of 1 year or less. Standard S3 is more cost effective than intelligent tiering.
Comment: The answer is C. * Intelligent tiering may not guarantee frequent, but random access and fast searches within a year. * Athena is a great analysis solution, but it is an unnecessary cost for search purposes only.
Comment: Answer is C. The only difference between choice B and C is Glacier Storage class. The question states clearly that "giving users the ability to query and retrieve files that are less than 1-year-old as quickly as possible". This is possible via instant retrieval and not flexible retrieval.
Comment: option B is the only one that mentions use of Amazon Athena and Glacier select for querying, So I'll go with it though I would have preferred using S3 standard storage in place of S3 intelligent tiering for the first year.
Comment: Answer is C - unfortunately. S3 Glacier Instant Retrieval - MOST Cost effective deep storage for retrieving files as quickly as possible.
Comment: B is good answer: Athena is good option to query data in S3. And before 1 year data are randomly use, for this, intelligent tiering is good option.
Comment: The company wants to optimize its solution by giving users the ability to query and retrieve files that are less than 1-year-old as quickly as possible" -- What if S3 Intelligent-Tiering transitioned the data that's under 1 year old into a storage class that takes a long time to access?
Comment: The answer is C S3 standard for first part (intelligent tiering is much better and cost-effective) glacier instant retrieval because of the statement after an year needs to retrieved as soon as possible) Also why ruling out B is because of Athena - it becomes expensive if data is retrieved using it after scanning all the data in glacier per request.
Comment: A: It does not account for random pattern of first year C: "Store search metadata for each archive in Amazon S3 Standard storage"... this part is wrong for me. Storing metadata forever in S3 so that it can be queries? This is why I won't select it. D: RDS is costly for storage and query just to know where your S3 object is. B is correct as Intelligent Tiering takes care of random frequency in first year in most cost effective way. Older object will end up in S3 glacier with flexible retrieval so cost effective. Athena doesn't care where your object is (s3 standard, IA or Glacier) and queries work.
Comment: According to the fact that S3 Std, Std-IA and One Zone-IA are Higher cost, frequent access storage classes and the fact that S3 Intelligent-Tiering is an additional storage class that provides flexibility for data with unknown or changing access patterns. It automates the movement of your objects between storage classes to optimize cost. Plus the requirement for MOST cost-effective solution, Answer B seems to be the right solution
Comment: If you watch Stephen Mareek's Udemy SSA video - anything after 1 year has to go with Amazon Athena
Comment: C is the most cost-effective given no Athena and the archive files don't need instant access. A delay is acceptable
Comment: quite tricky because B has better cost with flexible retrieval for files after 1 year. If counting in operation overhead then C is better. For cost-optimized, B can probably be better. Tricky question then
Comment: I picked "B" first, then switched to "C" because it asks for MORE cost-effective = Athena might be pricey: however: Access Patterns: If your data access patterns are predictable and consistent, and you do not require automatic tiering based on access frequency, S3 Standard might be a straightforward and cost-effective choice. Variable Access Patterns: If your data access patterns are variable or unpredictable, and you want automatic cost optimization based on access frequency, S3 Intelligent-Tiering might provide cost savings.
Comment: os usuarios acceden a los archivos de forma aleatoria. S3 Intelligent-Tiering es la clase de almacenamiento ideal para datos con patrones de acceso desconocidos, cambiantes o impredecibles, independientemente del tamaño del objeto o el período de retención. Puede utilizar S3 Intelligent-Tiering como clase de almacenamiento predeterminada para prácticamente cualquier carga de trabajo, especialmente lagos de datos, análisis de datos, nuevas aplicaciones y contenido generado por el usuario.
Comment: i think B would be for least operation overhead, but C only uses S3 which would make it most cost effective, no?
Comment: The primary focus of Patch Manager, a capability of AWS Systems Manager, is on installing operating systems security-related updates on managed nodes. By default, Patch Manager doesn't install all available patches, but rather a smaller set of patches focused on security. (Ref https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-selection.html) Run Command allows you to automate common administrative tasks and perform one-time configuration changes at scale. (Ref https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) Seems like patch manager is meant for OS level patches and not 3rd party applications. And this falls under run command wheelhouse to carry out one-time configuration changes (update of 3rd part application) at scale.
Comment: 3rd party applications are also supported by Patch Manager (https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html). You can use Patch Manager to apply patches for both operating systems and applications. (On Windows Server, application support is limited to updates for applications released by Microsoft.) You can use Patch Manager to install Service Packs on Windows nodes and perform minor version upgrades on Linux nodes. You can patch fleets of Amazon Elastic Compute Cloud (Amazon EC2) instances, edge devices, on-premises servers, and virtual machines (VMs) by operating system type. This includes supported versions of several operating systems, as listed in Patch Manager prerequisites.
Comment: D AWS Systems Manager Run Command allows the company to run commands or scripts on multiple EC2 instances. By using Run Command, the company can quickly and easily apply the patch to all 1,000 EC2 instances to remediate the security vulnerability. Creating an AWS Lambda function to apply the patch to all EC2 instances would not be a suitable solution, as Lambda functions are not designed to run on EC2 instances. Configuring AWS Systems Manager Patch Manager to apply the patch to all EC2 instances would not be a suitable solution, as Patch Manager is not designed to apply third-party software patches. Scheduling an AWS Systems Manager maintenance window to apply the patch to all EC2 instances would not be a suitable solution, as maintenance windows are not designed to apply patches to third-party software
Comment: Path Manager can support patch third party applications
Comment: Ans B (should be). Clue: "The company needs to *patch* the third-party software..." - if the Patch Manager is not capable of this then perhaps it should be, rather than delegating functionality to another service... The suggested answer D, implies Patch Manager can't do the job...
Comment: In your case, since the company needs to fix a critical security vulnerability as quickly as possible, Patch Manager (option B) would be the most recommended choice. It provides a quick and efficient way to apply the patch to all affected instances without the need to create custom scripts. However, if your company has specific requirements that cannot be met by Patch Manager, Run Command (option D) may be a viable alternative.
Comment: I originally thought B but after a bit of reading I've changed my mind to D purely because patch manager will not be aware of this random third party application. Run command allows you to install applications, run powershell, bash etc commands at scale so the most sensible answer would be run command.
Comment: Install software -> Patch Manager Run command/processing workload -> Run Command
Comment: I think patch manager would need an agent to be installed and also Patch Manager doesn't derive severity levels from third-party sources.
Comment: AWS Systems Manager Patch Manager primarily focuses on operating system patches and does not directly support third-party software patching on Linux instances
Comment: Critical means immediate. Just run the patch command with AWS SM run command to get it done. D is best choice. A: Too convoluted B: Can work but have to setup a lot of things to get this done. would be a good choice if D wasn't an option C: It's a critical patch so not time for maintenance window
Comment: By practice, isn't schedule planned downtime is common sense before patching done?
Comment: maintenance window will trigger the run command or the patch manager in the right time (as quickly as possible )
Comment: keyword - as quickly as possible Option B - efficient and reliable Option D - speed and immediate execution hence D is correct
Comment: Third party software - Custom command.
Comment: D - Patch manager does not understand severity for third party software . Patch Manager doesn't derive severity levels from third-party sources, such as the Common Vulnerability Scoring System (CVSS), or from metrics released by the National Vulnerability Database (NVD). https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html
Comment: I go with option B. To quickly patch third-party software on 1,000 EC2 instances, use AWS Systems Manager Patch Manager. It automates the patching process, from scanning for missing patches to applying the patch to all targeted instances. Patch Manager is designed for managing and automating the patching process for EC2 instances at scale.
Comment: Key: third-party software and run custom command
Comment: You can use SES to format the report in HTML. https://docs.aws.amazon.com/ses/latest/dg/send-email-formatted.html
Comment: this document is talking about the SES API. not ses. SES does not format data. just sending emails. https://aws.amazon.com/ses/
Comment: When you send an email with Amazon SES, the email information you need to provide depends on how you call Amazon SES. You can provide a minimal amount of information and have Amazon SES take care of all of the formatting for you. Or, if you want to do something more advanced like send an attachment, you can provide the raw message yourself. https://docs.aws.amazon.com/ses/latest/dg/send-email-concepts-email-format.html
Comment: B&D are the only 2 correct options. If you are choosing option E then you missed the daily morning schedule requirement mentioned in the question which cant be achieved with S3 events for SNS. Event Bridge can used to configure scheduled events (every morning in this case). Option B fulfills the email in HTML format requirement (by SES) and D fulfills every morning schedule event requirement (by EventBridge)
Comment: Option B doesn't specify an API interface...
Comment: I don't believe you are correct when you say that E cannot meet the scheduling requirement. If the glue action is scheduled and outputs to S3, then as the S3 event destination is SNS, in effect you have a way of getting SNS to have a scheduled release.
Comment: But E does not include a glue action. We need either C or D for the scheduling, plus B or E for the email sending.
Comment: the daily schedule can be achieve with event bridge - schedule and event bridge to trigger daily - the event briodge will trigger a lambda function that will collect data and save it in s3 - once data in s3 the event noitification will trigger SNS to send emails
Comment: D Explanation: EventBridge can be used to schedule regular invocations of a Lambda function that retrieves the required data from the application's API. This step sets up the process to collect the data at the specified time every morning. B Explanation: Amazon SES can format the data into an easy-to-read HTML report and send the email to multiple recipients efficiently.
Comment: SNS & Glue
Comment: BC - Question says extract the data - which is the job of AWS Glue and then invoke SES endpoint to send email. SES support html format. But BD also seems possible.
Comment: Defo B and D Look at the aws notes on Sns Notes You can't customize the body of the email message. The email delivery feature is intended to provide internal system alerts, not marketing messages. It can't send anything but notifications. SES can send normal emails therefore, BD is the answer.
Comment: Option B suggests using Amazon SES, which allows you to format the data and email the report to multiple recipients in an efficient and scalable way. Option E proposes storing application data in Amazon S3, which is scalable and durable storage. By configuring an Amazon SNS topic as an S3 event destination, you can automatically trigger the report to be sent via email whenever new data is added to S3.
Comment: Chat GPT says : With Amazon SES, you can send rich, formatted email content, including text, HTML, attachments, and embedded images, suitable for email communication. Amazon SNS is primarily used for sending plain-text or JSON-formatted messages, suitable for notifications and alerts across different channels. This can suggest that we need to use SES if we want to use HTML content.
Comment: Answer: B and D Other options A. Amazon Kinesis Data Firehose: This service is typically used for real-time streaming data processing rather than for scheduled tasks like generating a morning report. C. Amazon EventBridge to invoke an AWS Glue job: AWS Glue is a data integration service that's more focused on ETL (extract, transform, load) operations, often involving large datasets and complex transformations, which might be more than needed for this scenario. E. Amazon S3 with SNS topic: Storing data in S3 and using SNS for notification is viable, but this doesn't directly address the need to format the data into HTML and send it as an email report. SNS is better suited for sending notifications rather than formatted reports.
Comment: Some mistakes that Kinesis Data Firehose is used for near real-time streaming data processing. But totally I agree with you that B & D are correct.
Comment: Very detailed question so let's break it down: "send the report to several email addresses at the same time every morning" this locks B as nothing else can do it. A: Firehose to collect data from API will work but it cannot generate a report C: Glue is ETL, it cannot extract data from an API E: Store data in S3. No idea what this will help with The API provides order shipping data so you can query it. Lambda can be used to query the API easily so D is good choice that works with B. BD is correct combination
Comment: "At the same time every morning" requires scheduling, which is only mentioned in C and D. AWS Glue has no native functionality to query REST APIs, thus we need a Lambda function -> D. For email we need SES or SNS, but as we want "an easy-to-read HTML format", SNS is out. SNS can send notifications, not formatted emails. Thus B.
Comment: Key: Send email every morning same time - 1. Simple email 2. AWS Event Bridge with lambda
Comment: I think there is a problem with the answer. It should be that ses sends the email processed by lambda.
Comment: Key: retrieval by a REST API, that's why use lambda
Comment: Both SES and SNS can format html, but there is a disconnection between B and D. Where do you store the data between the steps?
Comment: Why would I need to "store the data"? Wouldn't the Lamba function just call the SES API?
Comment: the reason why "B" is more correct than "E" is because is more simple and you don't have to store data is not what they want, also SES is a service that is meant for sending the data through email, and is exactly what the company wants. is not the first time the admin is wrong with the answer
Comment: E should be correct: https://saturncloud.io/blog/how-to-send-html-mails-using-amazon-sns/
Comment: I believe BD are the answers. E can't be used, because, in E can't help with email formatting. E won't be the best choice even for scheduling.
Comment: EFS is a standard file system, it scales automatically and is highly available.
Comment: I have absolutely no idea... Output files that vary in size from tens of gigabytes to hundreds of terabytes Simit size for a single object: S3 5To TiB https://aws.amazon.com/fr/blogs/aws/amazon-s3-object-size-limit/ EBS 64 Tib https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html EFS 47.9 TiB https://docs.aws.amazon.com/efs/latest/ug/limits.html
Comment: None meets 100s of TB / file. Bit confusing / misleading
Comment: The answer to that is Limit size for a single object: S3, 5TiB is per object but you can have more than one object in a bucket, meaning infinity https://aws.amazon.com/fr/blogs/aws/amazon-s3-object-size-limit/ EBS 64 Tib is per block of storage https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html EFS 47.9 TiB per file and in the questions its says Files the 's' https://docs.aws.amazon.com/efs/latest/ug/limits.html
Comment: S3 and EBS are block storage but you are looking to store files, so EFS is the correct option.
Comment: S3 is object storage.
Comment: A lil correction,S3 is Object storage not Block Storage
Comment: Ans C - S3 unlimited storage in both scope and size of individual objects
Comment: C : EFS as It is built to scale on demand to petabytes without disrupting applications, growing and shrinking automatically as you add and remove files. Multiple compute instances, including Amazon EC2, Amazon ECS, and AWS Lambda, can access an Amazon EFS file system at the same time, providing a common data source for workloads.
Comment: Key words: Standard File System and Scales Automatically. S3 is object Store, hence if fails with the "Standard File System" requirement, so we can discard A. EBS does not scale automatically, failing with the "Scales Automatically" requirement, so we can discard B and D
Comment: C is the only option which supports standard file system when we talk about high availability. EBS scope is within a availability zone but EFS has scope of a region.
Comment: Standard file system that is highly available: EFS Autoscaling highly available system: EC2 or ECS or EKS can work A: Not suitable due to S3 which is BLOB not file system B: EKS is ok but EBS is not HA D: EBS is not HA So by elimination, C is best option.
Comment: "File system structure" = EFS, which also meets all the other requirements.
Comment: Technically the A could work, ECS is often recommended by AWS in case of minimum operational overhead, and S3 is durable and highly scalable BUT it is not a "traditional" file system structure. In an S3 bucket, there is no real file structure, only files and prefixes that simulate a structure. B is wrong because of EKS which require more management EFS is recommended for minimum operational overhead instead of EBS. So C (EC2 + EFS) is recommended here over D (EC2 + EBS).
Comment: Palabras clave: autoescalado y ficheros
Comment: The key is Multi-AZ ,EBS does not support it.
Comment: Standard file system structure, scales automatically, requires minimum operational overhead = Amazon Elastic File System (Amazon EFS)
Comment: Option C is the correct answer
Comment: EFS provides a scalable and fully managed file system that can be easily mounted to multiple EC2. It allows you to store and access files using the standard file system structure, which aligns with the company's requirement for a standard file system. EFS automatically scales with the size of your data. A suggests using ECS for container orchestration and S3 for storage. ECS doesn't offer a native file system storage solution. S3 is an object storage service and may not be the most suitable option for a standard file system structure. B suggests using EKS for container orchestration and EBS for storage. Similar to A, EBS is block storage and not optimized for file system access. While EKS can manage containers, it doesn't specifically address the file storage requirements. D suggests using EC2 with EBS for storage. While EBS can provide block storage for EC2, it doesn't inherently offer a scalable file system solution like EFS. You would need to manage and provision EBS volumes manually, which may introduce operational overhead.
Comment: Option C meets the requirements.
Comment: Keywords: file system structure, scales automatically, highly available, and minimal operational overhead
Comment: standard file system structure is the KEYWORD here, the S3 and EBS are not file based storage. EFS is. so the automatic answer is C
Comment: Only CD provides Object Lock options which is required for stopping admin/root users from deleting. D is governance mode which is like government, pay enough money and you can do anything. This is not what we want so compliance is the option. C is right choice. For future, remember S3 Lock Governance = corrupt government official S3 Lock Compliance = honest solution architect!
Comment: The key reasons are: The S3 Lifecycle policy transitions the data to Glacier Deep Archive after 1 year for long-term archival. S3 Object Lock in compliance mode prevents any user from deleting or overwriting objects for the specified retention period. Glacier Deep Archive provides very high durability and the lowest storage cost for long-term archival. Compliance mode ensures no one can override or change the retention settings even if policies change. This meets all the requirements - immediate access for 1 year, archived for 9 years, unable to delete for 10 years, maximum resiliency
Comment: Ans C - S3 Glacier after year 1 in compliance mode with object lock (=immutable lock)
Comment: No one at the company, including administrative users and root users, can be able to delete the records during the entire 10-year period = Compliance Mode
Comment: To meet the requirements of immediately accessible records for 1 year and then archived for an additional 9 years with maximum resiliency, we can use S3 Lifecycle policy to transition records from S3 Standard to S3 Glacier Deep Archive after 1 year. And to ensure that the records cannot be deleted by anyone, including administrative and root users, we can use S3 Object Lock in compliance mode for a period of 10 years. Therefore, the correct answer is option C. Reference: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.htmls
Comment: No one at the company, including administrative users and root users, can be able to delete the records during the entire 10-year period = Compliance Mode
Comment: Option C is the correct answer
Comment: Why not A? Move all files to S3 Glacier instant retrieval (Cheaper than S3) and then move files older than a year to S3 Deep archive.
Comment: Put entire 10 years to Glacier means it's not accessible for the 1 year window. Hence wrong answer.
Comment: To prevent deletion of records during the entire 10-year period, you can utilize S3 Object Lock feature. By enabling it in compliance mode, you can set a retention period on the objects, preventing any user, including administrative and root users, from deleting records. A: S3 Glacier is suitable for long-term archival, it may not provide immediate accessibility for the first year as required. B: Intelligent-Tiering may not offer the most cost-effective archival storage option for extended 9-year period. Changing the IAM policy after 10 years to allow deletion also introduces manual steps and potential human error. D: While S3 One Zone-IA can provide cost savings, it doesn't offer the same level of resiliency as S3 Glacier Deep Archive for long-term archival.
Comment: In compliance mode, a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html
Comment: Retention Period: A period is specified by Days & Years. With Retention Compliance Mode, you can't change/adjust (even by the account root user) the retention mode during the retention period while all objects within the bucket are Locked. With Retention Governance mode, a less restrictive mode, you can grant special permission to a group of users to adjust the Lock settings by using S3:BypassGovernanceRetention. Legal Hold: It's On/Off setting on an object version. There is no retention period. If you enable Legal Hole on specific object version, you will not be able to delete or override that specific object version. It needs S:PutObjectLegalHole as a permission.
Comment: S3 Glacier Deep Archive all day....
Comment: Use an S3 Lifecycle policy to transition the records from S3 Standard to S3 Glacier Deep Archive after 1 year. Use S3 Object Lock in compliance mode for a period of 10 years.
Comment: Use S3 Object Lock in compliance mode https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html
Comment: C, A lifecycle set to transition from standard to Glacier deep archive and use lock for the delete requirement A, B and D don't meet the requirements
Comment: C. Use an S3 Lifecycle policy to transition the records from S3 Standard to S3 Glacier Deep Archive after 1 year. Use S3 Object Lock in compliance mode for a period of 10 years. To meet the requirements, the company could use an S3 Lifecycle policy to transition the records from S3 Standard to S3 Glacier Deep Archive after 1 year. S3 Glacier Deep Archive is Amazon's lowest-cost storage class, specifically designed for long-term retention of data that is accessed rarely. This would allow the company to store the records with maximum resiliency and at the lowest possible cost.
Comment: To ensure that the records are not deleted during the entire 10-year period, the company could use S3 Object Lock in compliance mode. S3 Object Lock allows the company to apply a retention period to objects in S3, preventing the objects from being deleted until the retention period expires. By using S3 Object Lock in compliance mode, the company can ensure that the records are not deleted by anyone, including administrative users and root users, during the entire 10-year period.
Comment: A and B are ruled out as you need them to be accessible for 1 year and using control policy or IAM policies, the administrator or root still has the ability to delete them. D is ruled out as it uses One Zone-IA, but requirement says max- resiliency. SO- C should be the right answer.
Comment: EFS is not supported on Windows instances https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/AmazonEFS.html Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers, backed by a fully native Windows file system. https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html
Comment: Windows file shares = Amazon FSx for Windows File Server Hence, the correct answer is C
Comment: Taking back this answer. As explained in the latest update. ***CORRECT*** D: Extend the file share environment to Amazon Elastic File System (Amazon EFS) with a Multi-AZ configuration. Migrate all the data to Amazon EFS.
Comment: No, users should continue using SMB, which EFS doesn't support
Comment: Ans C - use FSx for Windows File Server - why create extra work by migrating to EFS? Add Multi-AZ configuration for availability
Comment: Amazon EFS (Linux) and Amazon FSx (Windows) provide highly durable and available file systems that can span multiple Availability Zones. Both solutions are designed to deliver high performance, however, when choosing to use network file systems consider the access patterns. https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-14-3.html
Comment: FSx=Windows https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html
Comment: Windows workload rules out S3 and EFS as they cannot be mounted directly on Windows. S3 File Gateway is mainly for on-prem to AWS which is not a requirement here as company is already in AWS. C meets all the requirements.
Comment: With Amazon FSx for Windows File Server, you can enjoy a native Windows file server experience with a fully managed, scalable, and highly dependable file storage solution
Comment: https://aws.amazon.com/fsx/windows/faqs/ Thousands of compute instances and devices can access a file system concurrently.
Comment: With Amazon FSx for Windows File Server, you can enjoy a native Windows file server experience with a fully managed, scalable, and highly dependable file storage solution. Rich administrative features including end-user file recovery, user quotas, and Microsoft Active Directory integration are all provided by this Windows Server-based system.
Comment: The key reasons are: FSx for Windows provides fully managed Windows-native SMB file shares that are accessible from Windows clients. It allows seamlessly migrating the existing Windows file shares to FSx shares without disrupting users. The Multi-AZ configuration provides high availability and durability for file storage. Users can continue to access files the same way over SMB without any changes. It is optimized for Windows workloads and provides features like user quotas, ACLs, AD integration. Data is stored on SSDs with automatic backups for resilience.
Comment: The company wants a highly available and durable storage solution that preserves how users currently access the files = Amazon FSx for Windows File Server
Comment: Option C is the correct answer
Comment: Migrating all the data to FSx for Windows File Server allows you to preserve existing user access method and maintain compatibility with Windows file shares. Users can continue accessing files using the same method as before, without any disruptions. A: S3 is a highly durable object storage service, it is not designed to directly host Windows file shares. Implementing IAM authentication for file access would require significant changes to existing user access method. B: S3 File Gateway can provide access to Amazon S3 objects through standard file protocols, it may not be ideal solution for preserving existing user access method and maintaining Windows file shares. D: Although Amazon EFS provides highly available and durable file storage, it may not directly support the existing Windows file shares and their access method.
Comment: https://aws.amazon.com/fsx/windows/faqs/ Thousands of compute instances and devices can access a file system concurrently. EFS does not support Windows
Comment: C is correct. Amazon FSx for Windows File Server.
Comment: EFS is not supported on Windows instances https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/AmazonEFS.html Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers, backed by a fully native Windows file system. https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html
Comment: C is correct. Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers.
Comment: A: doesn't fully configure the traffic flow B: security groups don't have deny rules D: peering is mostly between VPCs, doesn't really help here answer is C, most mainstream way
Comment: Just took the exam today and EVERY ONE of the questions came from this dump. Memorize it all. Good luck.
Comment: Hey bro, did you buy premium access?
Comment: Ans C - only one that makes sense: "...a security group that allows inbound traffic from the security group that is assigned to instances in the private subnets" - operative word: "allows"
Comment: A: route table that connect... no idea what this option is trying to do but won't work for RDS B: SG are deny by default D: Peering connection between subnets? No idea what this is but happy to learn if such a thing exists. C: SG to allow input to private subnet means everything else will be blocked. Attaching this SG to DB instance means it will block everything except the private subnet instances which is where the required EC2 instances are.
Comment: RDS databases can only be accessed by EC2 instances located in private subnets: From the security group given to instances in the private subnets, the DB instances' security group will permit incoming traffic. Because of this, the RDS databases will only be accessible by EC2 instances located on the private subnets. Because of its safe architecture, Every other source of incoming traffic will be blocked by the security group that is linked to the database instances. The RDS databases will be better shielded from unwanted access thanks to this.
Comment: The key reasons are: Using security groups to control access between resources is a standard practice in VPCs. The security group attached to the RDS DB instances can allow inbound traffic from the security group for the EC2 instances in the private subnets. This allows only those EC2 instances in the private subnets to connect to the databases, meeting the requirements. Route tables, peering connections, and denying public subnet access would not achieve the needed selectivity of allowing only the private subnet EC2 instances. Security groups provide stateful filtering at the instance level for precise access control.
Comment: Security groups only have allow rules
Comment: optoin C
Comment: Option C is the correct answer
Comment: Creating security group that allows inbound traffic from security group assigned to instances in private subnets ensures that only EC2 running in private subnets can access the RDS databases. By associating security group with DB, you restrict access to only instances that belong to designated security group. A: This approach may help control routing within VPC, it does not address the specific access requirement between EC2 instances and RDS databases. B: Using a deny rule in a security group can lead to complexities and potential misconfigurations. It is generally recommended to use allow rules to explicitly define access permissions. D: Peering connections enable communication between different VPCs or VPCs in different regions, and they are not necessary for restricting access between subnets within the same VPC.
Comment: Option C meets the requirements.
Comment: By default, a security group is set up with rules that deny all inbound traffic and permit all outbound traffic.
Comment: CCCCCCCCCCC
Comment: Create a security group that allows inbound traffic from the security group that is assigned to instances in the private subnets. Attach the security group to the DB instances. This will allow the EC2 instances in the private subnets to have access to the RDS databases while denying access to the EC2 instances in the public subnets.
Comment: The solution that meets the requirements described in the question is option C: Create a security group that allows inbound traffic from the security group that is assigned to instances in the private subnets. Attach the security group to the DB instances. In this solution, the security group applied to the DB instances allows inbound traffic from the security group assigned to instances in the private subnets. This ensures that only EC2 instances running in the private subnets can have access to the RDS databases.
Comment: Option A, creating a new route table that excludes the route to the public subnets' CIDR blocks and associating it with the database subnets, would not meet the requirements because it would block all traffic to the database subnets, not just traffic from the public subnets. Option B, creating a security group that denies inbound traffic from the security group assigned to instances in the public subnets and attaching it to the DB instances, would not meet the requirements because it would allow all traffic from the private subnets to reach the DB instances, not just traffic from the security group assigned to instances in the private subnets. Option D, creating a new peering connection between the public subnets and the private subnets and a different peering connection between the private subnets and the database subnets, would not meet the requirements because it would allow all traffic from the private subnets to reach the DB instances, not just traffic from the security group assigned to instances in the private subnets.
Comment: The real trick is between B and C. A and D are ruled out for obvious reasons. B is wrong as you cannot have deny type rules in Security groups. So- C is the right answer.
Comment: The key is "Only EC2 instances that run in the private subnets can have access to the RDS databases" The answer is C.
Comment: The correct solution to meet these requirements is option C. To design the API Gateway URL with the company's domain name and corresponding certificate, the company needs to do the following: 1. Create a Regional API Gateway endpoint: This will allow the company to create an endpoint that is specific to a region. 2. Associate the API Gateway endpoint with the company's domain name: This will allow the company to use its own domain name for the API Gateway URL. 3. Import the public certificate associated with the company's domain name into AWS Certificate Manager (ACM) in the same Region: This will allow the company to use HTTPS for secure communication with its APIs. 4. Attach the certificate to the API Gateway endpoint: This will allow the company to use the certificate for securing the API Gateway URL. 5. Configure Route 53 to route traffic to the API Gateway endpoint: This will allow the company to use Route 53 to route traffic to the API Gateway URL using the company's domain name.
Comment: Why the "reveal solution" most of the time gives the wrong answer ?
Comment: i read this before that they can't give 100% of the right answers legally or something
Comment: google bard reply..
Comment: Option C includes all the necessary steps to meet the requirements, hence it is the correct solution. Options A and D do not include the necessary steps to associate the API Gateway endpoint with the company's domain name and attach the certificate to the endpoint. Option B includes the necessary steps to associate the API Gateway endpoint with the company's domain name and attach the certificate, but it imports the certificate into the us-east-1 Region instead of the ca-central-1 Region where the API Gateway is located.
Comment: I think the answer is C. we don't need to attach a certificate in us-east-1, if is not for cloudfront. In our case the target is ca-central-1.
Comment: I think that is C too, the target would be the same Region. https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-regional-api-custom-domain-create.html
Comment: Agree, C is correct by using the API Gateway option "Custom domain names" https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html
Comment: Ans C - as per Buruguduystunstugudunstuy (1 year, 8 months ago) for the reasons therein... Not sure what Ans D is addressing...
Comment: Option C has all the steps to meet the requirenment and attach certificate in the same region
Comment: C for sure
Comment: BD are wrong because they are in wrong regions. A. Does not help with R53 routing to API Gateway and not sure what it's trying to do here C is correct
Comment: Important For an API Gateway Regional custom domain name, you must request or import the certificate in the same Region as your API.
Comment: All certificates in ACM are regional resources, including the certificates that you import. To use the same certificate with Elastic Load Balancing load balancers in different AWS Regions, you must import the certificate into each Region where you want to use it. To use a certificate with Amazon CloudFront, you must import it into the US East (N. Virginia) Region. https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html
Comment: Only if the API Gateway is global then the corresponding AWS ACM Certificate must be placed in us-east-1
Comment: Correct answer
Comment: A records support Elasticity and load balancing and by default resilience is Key in any configuration in AWS
Comment: now I am confused, I would have chosen C, but with a Closer look D might be right, because of the A records and again the region used and not stated can be for resilience. I think? can someone clarify
Comment: I think C is the correct answer, because the DNS record in this case must be an alias (cname). DNS A record is for IP address. Here some documentation that can be useful: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html
Comment: Explain why this saying a different region which not mentioned in the Q.
Comment: c is right The other options have various issues: Option A: Using stage variables and importing certificates into ACM is not sufficient for achieving the requirement of associating a custom domain and certificate with the API Gateway endpoint. Option B: While it mentions importing the certificate into ACM, it doesn't address the need for a Regional API Gateway or the appropriate region for the certificate. Option D: Using certificates from the us-east-1 region for a Regional API Gateway might cause issues. Additionally, it doesn't provide clear details on how to associate the domain name and certificate with the API Gateway endpoint.
Comment: C is the correct solution. To use a custom domain name with HTTPS for API Gateway: The API Gateway endpoint needs to be Regional, not private or edge-optimized. The ACM certificate must be requested in the same region as the API Gateway endpoint. The custom domain name is then mapped to the Regional API endpoint under API Gateway domain names. Route 53 is configured to route traffic to the API Gateway regional domain. The ACM certificate is attached to the API Gateway domain name to enable HTTP
Comment: Import the public certificate associated with the company's domain name into AWS Certificate Manager (ACM) in the same Region.
Comment: Option C is the correct answer
Comment: The best solution to meet these requirements would be option B: Use Amazon Rekognition to detect inappropriate content, and use human review for low-confidence predictions. Amazon Rekognition is a cloud-based image and video analysis service that can detect inappropriate content in images using its pre-trained label detection model. It can identify a wide range of inappropriate content, including explicit or suggestive adult content, violent content, and offensive language. The service provides high accuracy and low latency, making it a good choice for this use case.
Comment: Option A, using Amazon Comprehend, is not a good fit for this use case because Amazon Comprehend is a natural language processing service that is designed to analyze text, not images. Option C, using Amazon SageMaker to detect inappropriate content, would require significant development effort to build and train a custom machine learning model. It would also require a large dataset of labeled images to train the model, which may be time-consuming and expensive to obtain. Option D, using AWS Fargate to deploy a custom machine learning model, would also require significant development effort and a large dataset of labeled images. It may not be the most efficient or cost-effective solution for this use case. In summary, the best solution is to use Amazon Rekognition to detect inappropriate content in images, and use human review for low-confidence predictions to ensure that all inappropriate content is detected.
Comment: Good Answer is B : https://docs.aws.amazon.com/rekognition/latest/dg/moderation.html?pg=ln&sec=ft
Comment: Ans B - I'll go with ans B reluctantly because Rekognition seems to be primarily aimed at video/image content as opposed to language/text... and only because you can add the latter "You can add features [to Rekognition] that detect objects, text, unsafe content, analyze images/videos, and compare faces to your application using Rekognition's APIs." (https://docs.aws.amazon.com/rekognition/latest/dg/what-is.html)
Comment: https://aws.amazon.com/rekognition/ Automate and lower the cost of your image recognition and video analysis with machine learning
Comment: https://aws.amazon.com/rekognition/content-moderation/ Amazon Rekognition Content Moderation automates and streamlines your image and video moderation workflows using machine learning (ML), without requiring ML experience.
Comment: comprehend is for NLP sagemaker is for training and deploying ML and AI models deploying cutom models using fargate requires time and development effort wich is not recommended by the question
Comment: https://docs.aws.amazon.com/rekognition/latest/dg/moderation.html?pg=ln&sec=ft
Comment: You can easily incorporate image and video analysis to your applications with the help of Amazon Rekognition. Numerous functions are available to it, including as facial analysis, image classification, and object and scene identification. DetectModerationLabels is an operation that may be used with Amazon Rekognition to identify incorrect content in photos. By using this procedure, photos with violent, drug-related, tobacco-related, alcohol-related, hate-filled, or provocative material can be identified.
Comment: B is the best solution as far
Comment: Amazon Rekognition is a fully managed service that provides image and video analysis capabilities. It can be used to detect inappropriate content in images, such as nudity, violence, and hate speech. Amazon Rekognition is a good choice for this solution because it is a managed service, which means that the company does not have to worry about managing the infrastructure or the machine learning model. Rekognition is also highly accurate, and it can be used to detect a wide range of inappropriate content
Comment: Amazon Rekognition to the rescue...whooosh!
Comment: Using Amazon Rekognition for content moderation is a cost-effective and efficient solution that reduces the need for developing and training custom machine learning models, making it the best option in terms of minimizing development effort. A. Amazon Comprehend is a natural language processing service provided by AWS, primarily focused on text analysis rather than image analysis. C. Amazon SageMaker is a comprehensive machine learning service that allows you to build, train, and deploy custom machine learning models. It requires significant development effort to build and train a custom model. In addition, utilizing ground truth to label low-confidence predictions would further add to the development complexity and maintenance overhead. D. Similar to C, using AWS Fargate to deploy a custom machine learning model requires significant development effort.
Comment: Amazon Rekognition is a cloud-based image and video analysis service that can detect inappropriate content in images using its pre-trained label detection model. It can identify a wide range of inappropriate content, including explicit or suggestive adult content, violent content, and offensive language.
Comment: Option B
Comment: B AWS Rekognition to detect inappropriate content and use human review for low-confidence predictions. This option minimizes development effort because Amazon Rekognition is a pre-built machine learning service that can detect inappropriate content. Using human review for low-confidence predictions allows for more accurate detection of inappropriate content.
Comment: B is correct
Comment: Option B. https://docs.aws.amazon.com/rekognition/latest/dg/a2i-rekognition.html
Comment: Good answer is C: AWS Fargate is a serverless, pay-as-you-go compute engine that lets you focus on building applications without having to manage servers. AWS Fargate is compatible with Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). https://aws.amazon.com/fr/fargate/
Comment: Using ECS on Fargate allows you to run containers without the need to manage the underlying infrastructure. Fargate abstracts away the underlying EC2 and provides serverless compute for containers. A. This option would require manual provisioning and management of EC2, as well as installing and configuring Docker on those instances. It would introduce additional overhead and responsibilities for maintaining the underlying infrastructure. B. While this option leverages ECS to manage containers, it still requires provisioning and managing EC2 to serve as worker nodes. It adds complexity and maintenance overhead compared to the serverless nature of Fargate. D. This option still involves managing and provisioning EC2, even though an ECS-optimized AMI simplifies the process of setting up EC2 for running ECS. It does not provide the level of serverless abstraction and ease of management offered by Fargate.
Comment: Ans C - use Fargate to do all the management / deployment (which the company doesn't want to do)
Comment: ECS FARGATE
Comment: Managed containers = Fargate
Comment: AWS Fargate is a serverless, pay-as-you-go compute engine that lets you focus on building applications without having to manage servers. AWS Fargate is compatible with Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS).
Comment: In order to execute containerized apps without having to manage servers, AWS Fargate is a serverless compute engine for Amazon ECS. Amazon Elastic Compute Cloud (Amazon EC2) instance clusters no longer require provisioning, configuring, or scaling thanks to AWS Fargate. So that you can concentrate on developing and maintaining your applications, AWS Fargate handles the monotonous, repetitive labor of managing servers.
Comment: Option C is the correct answer.
Comment: C for Fargate
Comment: The company does not want to be responsible for provisioning and managing the underlying infrastructure that runs the containerized workload = Serverless compute for containers = AWS Fargate
Comment: Option C is the correct answer
Comment: AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html
Comment: ECS + Fargate
Comment: AWS Fargate will hide all the complexity for you
Comment: C. Use Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. AWS Fargate is a fully managed container execution environment that runs containers without the need to provision and manage underlying infrastructure. This makes it a good choice for companies that want to focus on maintaining their critical applications and do not want to be responsible for provisioning and managing the underlying infrastructure. Option A involves installing Docker on Amazon EC2 instances, which would still require the company to manage the underlying infrastructure. Option B involves using Amazon ECS on Amazon EC2 worker nodes, which would also require the company to manage the underlying infrastructure. Option D involves using Amazon EC2 instances from an Amazon ECS-optimized Amazon Machine Image (AMI), which would also require the company to manage the underlying infrastructure.
Comment: Option C
Comment: Obviously anything with EC2 in the answer is wrong...
Comment: Option D is the most appropriate solution for transmitting and processing the clickstream data in this scenario. Amazon Kinesis Data Streams is a highly scalable and durable service that enables real-time processing of streaming data at a high volume and high rate. You can use Kinesis Data Streams to collect and process the clickstream data in real-time. Amazon Kinesis Data Firehose is a fully managed service that loads streaming data into data stores and analytics tools. You can use Kinesis Data Firehose to transmit the data from Kinesis Data Streams to an Amazon S3 data lake. Once the data is in the data lake, you can use Amazon Redshift to load the data and perform analysis on it. Amazon Redshift is a fully managed, petabyte-scale data warehouse service that allows you to quickly and efficiently analyze data using SQL and your existing business intelligence tools.
Comment: Option A, which involves using AWS Data Pipeline to archive the data to an Amazon S3 bucket and running an Amazon EMR cluster with the data to generate analytics, is not the most appropriate solution because it does not involve real-time processing of the data. Option B, which involves creating an Auto Scaling group of Amazon EC2 instances to process the data and sending it to an Amazon S3 data lake for Amazon Redshift to use for analysis, is not the most appropriate solution because it does not involve a fully managed service for transmitting the data from the processing layer to the data lake. Option C, which involves caching the data to Amazon CloudFront, storing the data in an Amazon S3 bucket, and running an AWS Lambda function to process the data for analysis when an object is added to the S3 bucket, is not the most appropriate solution because it does not involve a scalable and durable service for collecting and processing the data in real-time.
Comment: The question does not say that real-time is needed here
Comment: Question asks how to "transmit and process the clickstream data", NOT how to analyze it. Thus D.
Comment: Option D. https://aws.amazon.com/es/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/
Comment: Unsure if this is right URL for this scenario. Option D is referring to S3 and then Redshift. Whereas URL discuss about eliminating S3 :- We're excited to launch Amazon Redshift streaming ingestion for Amazon Kinesis Data Streams, which enables you to ingest data directly from the Kinesis data stream without having to stage the data in Amazon Simple Storage Service (Amazon S3). Streaming ingestion allows you to achieve low latency in the order of seconds while ingesting hundreds of megabytes of data into your Amazon Redshift cluster.
Comment: Ans D - using Kinesis Streams / Firehouse (data in/out) is fast and reliable. Using Redshift allows all sorts of permutations of data analyses and interfacing to user apps
Comment: D is the best option
Comment: A: Not sure how recent this question is but Data Pipeline is not really a product AWS is recommending anymore https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/what-is-datapipeline.html B: 30TB of clickstream data could be done with EC2 but it would be challenging C: CloudFront is for CDN and caching and mostly outgoing data, not incoming. D: Kinesis, S3 data lake and Redshift will work perfectly for this case
Comment: The answer should be A. Clickstream does not mean real time, it just means they capture user interactions on the web page. Kinesis data streaming is not required. Furthermore, redshift is a data warehousing solution, it cant run complex analysis as well as EMR. My vote goes for A
Comment: Question asks how to "transmit and process the clickstream data", NOT how to analyze it. Also question does NOT ask how to archive the data (as is mentioned in A). Thus D.
Comment: when you see clickstream data, think about Kinesis Data Stream
Comment: The key reasons are: Kinesis Data Streams can continuously capture and ingest high volumes of clickstream data in real-time. This handles the large 30TB daily data intake. Kinesis Firehose can automatically load the streaming data into S3. This creates a data lake for further analysis. Firehose can transform and analyze the data in flight before loading to S3 using Lambda. This enables real-time processing. The data in S3 can be easily loaded into Amazon Redshift for interactive analysis at scale. Kinesis auto scales to handle the high data volumes. Minimal effort is needed for infrastructure management.
Comment: Option D is the correct answer
Comment: A. This option utilizes S3 for data storage and EMR for analytics, Data Pipeline is not ideal service for real-time streaming data ingestion and processing. It is better suited for batch processing scenarios. B. This option involves managing and scaling EC2, which adds operational overhead. It is also not real-time streaming solution. Additionally, use of Redshift for analyzing clickstream data might not be most efficient or cost-effective approach. C. CloudFront is CDN service and is not designed for real-time data processing or analytics. While using Lambda to process data can be an option, it may not be most efficient solution for processing large volumes of clickstream data. Therefore, collecting the data from Kinesis Data Streams, using Kinesis Data Firehose to transmit it to S3 data lake, and loading it into Redshift for analysis is the recommended approach. This combination provides scalable, real-time streaming solution with storage and analytics capabilities that can handle high volume of clickstream data.
Comment: Clickstream is the key - Answer is D
Comment: I am going to be unpopular here and I'll go for A). Even if here are other services that offer a better experience, data Pipeline can do the job here. "you can use AWS Data Pipeline to archive your web server's logs to Amazon Simple Storage Service (Amazon S3) each day and then run a weekly Amazon EMR (Amazon EMR) cluster over those logs to generate traffic reports" https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/what-is-datapipeline.html In the question there is no specific timing requirement for analytics. Also the EMR cluster job can be scheduled be executed daily. Option D) is a valid answer too, however with Amazon Redshift Streaming Ingestion "you can connect to Amazon Kinesis Data Streams data streams and pull data directly to Amazon Redshift without staging data in S3" https://aws.amazon.com/redshift/redshift-streaming-ingestion. So in this scenario Kinesis Data Firehose and S3 are redundant.
Comment: I think I agree with you, I does not make sense in option D) using Amazon Kinesis Data Firehose to transmit the data to an Amazon S3 data lake and then to Redshift, as you can send directly the data from Firehose to Redshift.
Comment: Also the Kinesis family is related to real time or near real time services. This is not a requirement at all. We have to process data daily, but not need to do it in real time
Comment: Question asks how to "transmit and process the clickstream data", NOT how to analyze it. This picture shows exactly scenario D: Producer - Kinesis - Intermediate S3 bucket - Redshift https://d2908q01vomqb2.cloudfront.net/b6692ea5df920cad691c20319a6fffd7a4a766b8/2020/07/30/StreamTransformAnalyzeKinesisLambdaRedshift1.png
Comment: Option D
Comment: It is C. The image in here https://aws.amazon.com/kinesis/data-firehose/ shows how kinesis can send data collected to firehose who can send it to Redshift. It is also possible to use an intermediary S3 bucket between firehose and redshift. See image in here https://aws.amazon.com/blogs/big-data/stream-transform-and-analyze-xml-data-in-real-time-with-amazon-kinesis-aws-lambda-and-amazon-redshift/
Comment: Makes sense, but this is D, not C
Comment: Why not A? You can collect data with AWS Data Pipeline and then analyze it with EMR. Whats wrong with this option?
Comment: It's not A, the wording is tricky! It says "to archive the data to S3" - there is no mention of archiving in the question, so it has to be D :)
Comment: And, the the question is not asking about analyzing the data at all, just about "transmitting and processing".
Comment: D is correct
Comment: Click Stream & Analyse/ process- Think KDS,
Comment: C. Create a listener rule on the ALB to redirect HTTP traffic to HTTPS. To meet the requirement of forwarding all requests to the website so that the requests will use HTTPS, a solutions architect can create a listener rule on the ALB that redirects HTTP traffic to HTTPS. This can be done by creating a rule with a condition that matches all HTTP traffic and a rule action that redirects the traffic to the HTTPS listener. The HTTPS listener should already be configured to accept HTTPS traffic and forward it to the target group.
Comment: Option A. Updating the ALB's network ACL to accept only HTTPS traffic is not a valid solution because the network ACL is used to control inbound and outbound traffic at the subnet level, not at the listener level. Option B. Creating a rule that replaces the HTTP in the URL with HTTPS is not a valid solution because this would not redirect the traffic to the HTTPS listener. Option D. Replacing the ALB with a Network Load Balancer configured to use Server Name Indication (SNI) is not a valid solution because it would not address the requirement to redirect HTTP traffic to HTTPS.
Comment: Answer C : https://docs.aws.amazon.com/fr_fr/elasticloadbalancing/latest/application/create-https-listener.html https://aws.amazon.com/fr/premiumsupport/knowledge-center/elb-redirect-http-to-https-using-alb/
Comment: A. Network ACLs operate at subnet level and control inbound and outbound traffic. Updating the network ACL alone will not enforce the redirection of HTTP to HTTPS. B. This approach would require modifying application code or server configuration to perform URL rewrite. It is not an optimal solution as it adds complexity and potential maintenance overhead. Moreover, it does not leverage the ALB's capabilities for handling HTTP-to-HTTPS redirection. D. While NLB can handle SSL/TLS termination using SNI for routing requests to different services, replacing the ALB solely to enforce HTTP-to-HTTPS redirection would be an unnecessary and more complex solution. Therefore, the recommended approach is to create a listener rule on the ALB to redirect HTTP traffic to HTTPS. By configuring a listener rule, you can define a redirect action that automatically directs HTTP requests to their corresponding HTTPS versions.
Comment: Ans C - don't re-invent; just re-direct
Comment: https://repost.aws/knowledge-center/elb-redirect-http-to-https-using-alb Steps 6-8 tells exactly how to do this: "6. Select a load balancer, and then choose HTTP Listener. 7. Under Rules, choose View/edit rules. 8. Choose Edit Rule to modify the existing default rule to redirect all HTTP requests to HTTPS. Or, insert a rule between the existing rules (if appropriate for your use case)."
Comment: C. Create a listener rule on the ALB to redirect HTTP traffic to HTTPS.
Comment: This solution meets all of the requirements: Forward all requests to the website so that the requests will use HTTPS: The ALB can be configured to redirect all HTTP traffic to HTTPS. The other options are not as good for this scenario: A. Updating the ALB's network ACL to accept only HTTPS traffic will prevent users from accessing the website using HTTP. B. Creating a rule that replaces the HTTP in the URL with HTTPS will not prevent users from accessing the website using HTTP. D. Replacing the ALB with a Network Load Balancer configured to use Server Name Indication (SNI) is not necessary because the ALB can be configured to redirect all HTTP traffic to HTTPS.
Comment: I hate this question description "The company wants to forward all requests to the website so that the requests will use HTTPS."
Comment: The best solution is to create a listener rule on the Application Load Balancer (ALB) to redirect HTTP traffic to HTTPS (option C). Here is why: ALB listener rules allow you to redirect traffic from one listener port (e.g. 80 for HTTP) to another (e.g. 443 for HTTPS). This achieves the goal to forward all requests over HTTPS. Network ACLs control traffic at the subnet level and cannot distinguish between HTTP and HTTPS requests to implement a redirect (option A incorrect). Replacing HTTP with HTTPS in the URL happens at the client side. It does not redirect at the ALB (option B incorrect). Network Load Balancers work at the TCP level and do not understand HTTP or HTTPS protocols. So they cannot redirect in this manner (option D incorrect).
Comment: Option C is the correct answer
Comment: A solutions architect should create listen rules to direct http traffic to https.
Comment: C is correct. Traffic redirection will solve it.
Comment: This rule can be created in the following way: 1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. 2. In the navigation pane, choose Load Balancers. 3. Select the ALB and choose Listeners. 4. Choose View/edit rules and then choose Add rule. 5. In the Add Rule dialog box, choose HTTPS. 6. In the Default action dialog box, choose Redirect to HTTPS. 7. Choose Save rules. This listener rule will redirect all HTTP requests to HTTPS, ensuring that all traffic is encrypted.
Comment: Configure an HTTPS listener on the ALB: This step involves setting up an HTTPS listener on the ALB and configuring the security policy to use a secure SSL/TLS protocol and cipher suite. Create a redirect rule on the ALB: The redirect rule should be configured to redirect all incoming HTTP requests to HTTPS. This can be done by creating a redirect rule that redirects HTTP requests on port 80 to HTTPS requests on port 443. Update the DNS record: The DNS record for the website should be updated to point to the ALB's DNS name, so that all traffic is routed through the ALB. Verify the configuration: Once the configuration is complete, the website should be tested to ensure that all requests are being redirected to HTTPS. This can be done by accessing the website using HTTP and verifying that the request is redirected to HTTPS.
Comment: Option C
Comment: C To redirect HTTP traffic to HTTPS, a solutions architect should create a listener rule on the ALB to redirect HTTP traffic to HTTPS. Option A is not correct because network ACLs do not have the ability to redirect traffic. Option B is not correct because it does not redirect traffic, it only replaces the URL. Option D is not correct because a Network Load Balancer does not have the ability to handle HTTPS traffic.
Comment: C is correct
Comment: Secrets manager supports Autorotation unlike Parameter store.
Comment: Parameter store does not support autorotation.
Comment: The correct solution is C. Store the database credentials as a secret in AWS Secrets Manager. Turn on automatic rotation for the secret. Attach the required permission to the EC2 role to grant access to the secret. AWS Secrets Manager is a service that enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. By storing the database credentials as a secret in Secrets Manager, you can ensure that they are not hardcoded in the application and that they are automatically rotated on a regular basis. To grant the EC2 instance access to the secret, you can attach the required permission to the EC2 role. This will allow the application to retrieve the secret from Secrets Manager as needed.
Comment: Option A, storing the database credentials in the instance metadata and using a Lambda function to update them, would not meet the requirement of not hardcoding the credentials in the application. Option B, storing the database credentials in an encrypted S3 bucket and using a Lambda function to update them, would also not meet this requirement, as the application would still need to access the credentials from the configuration file. Option D, storing the database credentials as encrypted parameters in AWS Systems Manager Parameter Store, would also not meet this requirement, as the application would still need to access the encrypted parameters in order to use them.
Comment: Ans C - Secrets Manager, provides rotation - and also a lot more API calls
Comment: parameter store does not have auto rotation
Comment: test kjlshfjkh jfskjfnkj kj bskjfb kj kjs bfkjs b kjf
Comment: Secrets Manager is purpose built for this scenario AB are wrong and insecure way of doing this D Parameter store with encrypted string can be used for this but is not ideal choice and AFAIK it does not support automatic rotation without extra programming
Comment: C - "Auto Rotation"
Comment: AWS Secrets Manager is a service that enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. By storing the database credentials as a secret in Secrets Manager, you can ensure that they are not hardcoded in the application and that they are automatically rotated on a regular basis. To grant the EC2 instance access to the secret, you can attach the required permission to the EC2 role.
Comment: Storing the credentials in AWS Secrets Manager and enabling automatic rotation meets the requirements with the least operational overhead. The EC2 instance role just needs permission to access the secret, and Secrets Manager handles rotating the credentials automatically on a schedule.
Comment: Key Autorotation = AWS Secrets Manager
Comment: Option C is the right answer.
Comment: Storing the credentials in Secrets Manager provides dedicated and secure management. With automatic rotation enabled, Secrets Manager handles the credential updates automatically. Attaching the necessary permissions to the EC2 role allows the application to securely access the secret. This approach minimizes operational overhead and provides a secure and managed solution for credential management.
Comment: The solution that meets the requirements with the least operational overhead, is option C.
Comment: My choice is c.
Comment: The right option is C.
Comment: C is the most correct answer. Automatic replacement must be performed by the secret manager.
Comment: Option C - As the requirement is to rotate the secrets Secrets manager is the one that can support it.
Comment: It's a third-party certificate, hence AWS cannot manage renewal automatically. The closest thing you can do is to send a notification to renew the 3rd party certificate.
Comment: It is D, because ACM does not manage the renewal process for imported certificates. You are responsible for monitoring the expiration date of your imported certificates and for renewing them before they expire. Check this question on the link below: Q: What types of certificates can I create and manage with ACM? https://www.amazonaws.cn/en/certificate-manager/faqs/#Managed_renewal_and_deployment
Comment: Ans D - hint: we're importing the certificate "...Use AWS Certificate Manager (ACM) to import an SSL/TLS certificate"
Comment: Yes it's D. Here is a clear explanation. Imported certificates – If you want to use a third-party certificate with Amazon CloudFront, Elastic Load Balancing, or Amazon API Gateway, you may import it into ACM using the AWS Management Console, AWS CLI, or ACM APIs. ACM can not renew imported certificates, but it can help you manage the renewal process. You are responsible for monitoring the expiration date of your imported certificates and for renewing them before they expire. You can use ACM CloudWatch metrics to monitor the expiration dates of an imported certificates and import a new third-party certificate to replace an expiring one. https://www.amazonaws.cn/en/certificate-manager/faqs/#Managed_renewal_and_deployment
Comment: "certificate that is issued by an external certificate authority (CA)" AB will create a new certificate in AWS C will also create a new certificate but this is not what PCA are for *=(https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) D: Import the certificate is correct answer
Comment: D - "External CA" --> 'Update Manually'
Comment: internal CA are typically trusted only within the organization unless you manually distribute and trust the root certificate elsewhere external CA: Certificates from a well-known external CA are trusted by most browsers and systems by default https://docs.aws.amazon.com/acm/latest/userguide/acm-certificate.html "Public certificates that you request through ACM are obtained from Amazon Trust Services, an Amazon managed public certificate authority (CA). ... Any browser, application, or OS that includes the Amazon or Starfield roots will trust public certificates obtained from ACM." The answer is A, different story if they said external certificate
Comment: : What types of certificates can I create and manage with ACM? https://www.amazonaws.cn/en/certificate-manager/faqs/#Managed_renewal_and_deployment
Comment: answer is D
Comment: The key points are: Obtain certificate from external CA, not ACM Import the external certificate into ACM Apply imported certificate to the ALB Set up EventBridge rule to trigger notification on certificate expiration Manually renew and rotate the external certificate each year.
Comment: Option D is the right answer.
Comment: D: With this approach, you import the third-party certificate into ACM, which allows you to centrally manage and apply it to the ALB. By configuring CloudWatch Events, you can receive notifications when the certificate is close to expiring, prompting you to manually initiate the rotation process. A & B: These options assume that the SSL/TLS certificate can be issued directly by ACM. However, since the requirement specifies that the certificate should be issued by an external certificate authority (CA), this option is not suitable. C: ACM Private Certificate Authority is used when you want to create your own private CA and issue certificates from it. It does not support certificates issued by external CAs. Therefore, this option is not suitable for the given requirement.
Comment: D is correct, since it's an external certificate
Comment: Option D meets these requirements.
Comment: Since the external certificate, you can't automate it. Only u can do is getting notefication, and renew it manually, no other way roud.
Comment: In the question it mentions that it's a third-party certificate. AWS has not got much control of third-party certificates and cannot manage renewal automatically. The closest thing you can do is to send a notification to renew the 3rd party certificate.
Comment: EXTERNAL certofocation is the key - Manual rotation is required so Answer is D
Comment: Option A. Elastic BeanStalk is expensive, and DocumentDB has a 400KB max to upload files. So Lambda and S3 should be the one.
Comment: is lambda scalable as an EC2 ?
Comment: lambda has near inifinite scale
Comment: In addition to this Lambda is paid only when used....
Comment: I'm thinking when you wrote DocumentDB you meant it as DynamoDB...yes?
Comment: Yes, DynamoDB has 400KB limit for the item. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html
Comment: B. Using DynamoDB for storing and processing large .pdf files would not be cost-effective due to storage and throughput costs associated with DynamoDB. C. Using Elastic Beanstalk with EC2 and EBS storage can work, but it may not be most cost-effective solution. It involves managing the underlying infrastructure and scaling manually. D. Similar to C, using Elastic Beanstalk with EC2 and EFS storage can work, but it may not be most cost-effective solution. EFS is a shared file storage service and may not provide optimal performance for conversion process, especially as demand and file sizes increase. A. leverages Lambda and the scalable and cost-effective storage of S3. With Lambda, you only pay for actual compute time used during the file conversion, and S3 provides durable and scalable storage for both .pdf files and .jpg files. The S3 PUT event triggers Lambda to perform conversion, eliminating need to manage infrastructure and scaling, making it most cost-effective solution for this scenario.
Comment: Ans A - a simple get and PUT back to S3 bucket. At "...average 5 MB" the returned .jpeg files should be smaller than standard S3
Comment: BeanStack is expensive solution, and dynamoDB have a limitation of 400KB max to upload files. So Lambda an S3 should be the one.
Comment: Given the company's requirement for access to both AWS and on-premises file storage with minimum latency and no significant changes to existing file access patterns, the most suitable option is: A. Deploy and configure Amazon FSx for Windows File Server on AWS. Move the on-premises file data to FSx for Windows File Server. Reconfigure the workloads to use FSx for Windows File Server on AWS.
Comment: S3 is the only scalable option for such a large user base in cost effective way. BCD can work but will be extremely costly
Comment: B. Using DynamoDB for storing and processing large .pdf files would not be cost-effective due to storage and throughput costs associated with DynamoDB. C. Using Elastic Beanstalk with EC2 and EBS storage can work, but it may not be most cost-effective solution. It involves managing the underlying infrastructure and scaling manual
Comment: Option A is the most cost-effective solution that meets the requirements. Here is why: Storing the PDFs in Amazon S3 is inexpensive and scalable storage. Using S3 events to trigger Lambda functions to do the file conversion is a serverless approach that scales automatically. No need to manage EC2 instances. Lambda usage is charged only for compute time used, which is cost-efficient for spiky workloads like this. Storing the converted JPGs back in S3 keeps the storage scalable and cost-effective.
Comment: Option A is right answer since Dynamo DB has size limitations.
Comment: Option A is the right answer.
Comment: The solution meets these requirements most cost-effectively is option A.
Comment: I think the best solution is A. Ref. https://s3.amazonaws.com/doc/s3-developer-guide/RESTObjectPUT.html
Comment: Since this requires a cost-effect solution then you can use Lambda to convert pdf files to jpeg and store them on S3. Lambda is serverless, so only pay when you use it and automatically scales to cope with demand.
Comment: if Option A is correct, however storing the data back to the same S3, wont it cause infinite looping, it's not best practice right storing a object that is processed by Lambda function to the same S3 bucket, it has chances to cause infinite Loop and then if the option B cant we increase the limits of Dynamo DB requesting AWS?
Comment: In question, it is never mentioned that the jpg files will also be stored in same s3 bucket. We can have different s3 buckets right ?
Comment: Answer A is the most cost effective solution that meets the requirement
Comment: Key words: MOST cost-effectively, so S3 + Lambda
Comment: This solution will meet the company's requirements in a cost-effective manner because it uses a serverless architecture with AWS Lambda to convert the files and store them in S3. The Lambda function will automatically scale to meet the demand for file conversions and S3 will automatically scale to store the original and converted files as needed.
Comment: https://www.examtopics.com/discussions/amazon/view/83281-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Agree answer is D) --- Requirements are: - "Users and applications interact with the data each day" - "the company requires access to AWS and on-premises file storage with minimum latency" --- Explanation: Answer A) will work with the same on-prem <> aws latency as in answer D) as both use the VPN Connection. Having said this, by using an Amazon FSx File Gateway on premise as the D) scenario mentioned, all users will have a great benefit on using the cache that the FSx File Gateway has on their daily workloads. And that is part of the requierements: "users", "each day", "latency"
Comment: D IS WRONG - Its used for caching. you cannot 'Move the on-premises file data to the FSx File Gateway.' which is stated in answer D. It pretty sure AWS employee's are spamming this site with the wrong answers intentionally.
Comment: I think D is correct. The FSx File gateway will look like any other Windows file share to the on-prem clients so when they write, or "Copy" data to the share it will be be cached locally and also written to the FSx service in the cloud. https://docs.aws.amazon.com/filegateway/latest/filefsxw/file-gateway-fsx-concepts.html
Comment: What's the problem with it being a cache? They did say "the company requires access to AWS and on-premises file storage with minimum latency." Not discarding what you said but what's wrong here?
Comment: you don't move data to gateway, its cached when people use those files from Fsx server
Comment: The problem with cache is - It needs to refreshed, which is an overkill for a migration project The cache refresh requires another solution since the users/applications interact with it daily which means it does modify often.
Comment: Ans A - it can only be A or D. With D introducing unnecessary operations for an eventual AWS migration
Comment: The question says the company is moving it's workload from windows to AWS. Plus D involves operational overhead.
Comment: Bad question. A - Doesn't meet the "low latency" requirement due to VPN connection. D - It's not possible to "move file data to FSx File Gateway". Instead, it provides improved latency with local caching. B and C - wrong, since the question requires "no significant changes to the existing file access patterns" I'd go with D, but not 100% happy with it.
Comment: A. Deploy and configure Amazon FSx for Windows File Server on AWS. Move the on-premises file data to FSx for Windows File Server. Reconfigure the workloads to use FSx for Windows File Server on AWS.
Comment: keyword as company continue to migrate workload from om-prem to cloud
Comment: I would go with option A as question mentions "solution that minimizes operational overhead" . Adding FSx File Gateway would add more complexity. They already have Site to Site VPN. This way min change required.
Comment: Will go with option D as option A is missing the Fsx File gateway component deployed on-premise which will provide the low latency access.
Comment: Option D is Correct, D provides low latency options for both of premium and the cloud loads.
Comment: *on-prem*
Comment: min. operational overhead.
Comment: Option D suggests deploying both Amazon FSx for Windows File Server on AWS and an Amazon FSx File Gateway on premises. While this option may provide a solution for accessing on-premises file data in AWS, it introduces additional complexity and potential overhead that may not be necessary given the company's existing AWS Site-to-Site VPN connectivity. Here are some reasons why Option D may not be the most suitable choice: Complexity, Cost, Redundancy and Operational Overhead.
Comment: Both Amazon FSx file gateway on-prem and Amazon FSx for windows file server goes hand in hand. So there is no way you can use the file gateway on-Prem and not use the Fsx for windows file server. Your conclusion of adding more overhead does not hold. Hence D is the perfect answer. Configure the cloud workloads to use FSx for Windows File Server on AWS. Configure the on-premises workloads to use the FSx File Gateway.
Comment: A VPN or DX connection is required for FSx File gateway. Option D provides low mantiance as FSx for Windows is a managed service and the file gateway will provide the low latency access required by the on-prem services.
Comment: D: FSX File gateway is nessary for communication between on-premise and aws FSX for window
Comment: Windows File Servers + Preserve compatibility so BC is wrong due to S3 A does not provide on-premise access and suggest to move the files which is wrong as company wants to keep on-prem access D meets all the requirements.
Comment: To meet the company's requirements of accessing both AWS and on-premises file storage with minimum latency, while minimizing operational overhead and maintaining existing file access patterns, a solutions architect should choose Option A: Deploy and configure Amazon FSx for Windows File Server on AWS. This option allows for the deployment of FSx for Windows File Server on AWS, facilitating the migration of on-premises file data to FSx. By reconfiguring the workloads to use FSx for Windows File Server on AWS, the company can ensure seamless access to the file data while leveraging the benefits of AWS infrastructure. This solution aligns with the company's objective of moving Windows workloads to AWS and utilizes the existing AWS Site-to-Site VPN connection for connectivity.
Comment: Amazon FSx File Gateway is a service that provides low latency and efficient access to Amazon FSx for Windows File Server shares from on-premises facilities. It helps eliminate on-premises file servers and consolidates all the data into AWS to take advantage of the scale and economics of cloud storage
Comment: A does not include any on-premises component, thus it can't meet the "access to ... on-premises file storage with minimum latency" requirement. B and C use S3 which cannot be directly accessed by the Windows servers they are going to move to AWS.
Comment: Option A is correct because - minimum latency -minimum operational overhead -requires no significant changes to the existing file access patterns Option D is incorrect - -Amazon FSx File Gateway on premises, which would add additional complexity and potential latency, , as the data would need to be transferred between the on-premises gateway and AWS. These options would also require reconfiguring the workloads to use the gateways, which could involve significant changes to the existing file access patterns. -unnecessary complexity and potential latency
Comment: A does not include any on-premises component, how would it meet the "access to ... on-premises file storage with minimum latency" requirement?
Comment: The correct solution is C: Use Amazon Textract to extract the text from the reports. Use Amazon Comprehend Medical to identify the PHI from the extracted text. Option C: Using Amazon Textract to extract the text from the reports, and Amazon Comprehend Medical to identify the PHI from the extracted text, would be the most efficient solution as it would involve the least operational overhead. Textract is specifically designed for extracting text from documents, and Comprehend Medical is a fully managed service that can accurately identify PHI in medical text. This solution would require minimal maintenance and would not incur any additional costs beyond the usage fees for Textract and Comprehend Medical.
Comment: Option A: Using existing Python libraries to extract the text and identify the PHI from the text would require the hospital to maintain and update the libraries as needed. This would involve operational overhead in terms of keeping the libraries up to date and debugging any issues that may arise. Option B: Using Amazon SageMaker to identify the PHI from the extracted text would involve additional operational overhead in terms of setting up and maintaining a SageMaker model, as well as potentially incurring additional costs for using SageMaker. Option D: Using Amazon Rekognition to extract the text from the reports would not be an effective solution, as Rekognition is primarily designed for image recognition and would not be able to accurately extract text from PDF or JPEG files.
Comment: Ans C - Textract to 'read' data; Comprehend to assess whether its PHI
Comment: Textract = Extract text from PDF/iamges Comprehend Medical = PHI ABD are wrong products for this requirement so won't achieve the results
Comment: Both Rekognition and Textract possess the ability to detect text within images, yet they are optimized for differing applications. Rekognition specializes in identifying text located spatially within an image, for instance, words displayed on street signs, t-shirts, or license plates. Its typical use cases encompass visual search, content filtering, deriving insights from content, among others. However, it's not the ideal choice for images containing more than 100 words, as this exceeds its limitation. On the other hand, Textract is tailored more towards processing documents and PDFs, offering a comprehensive suite for Optical Character Recognition (OCR). It proves useful in scenarios involving financial reports, medical records, receipts, ID documents, and more.
Comment: The correct solution is C: Use Amazon Textract to extract the text from the reports. Use Amazon Comprehend Medical to identify the PHI from the extracted text. Option C: Using Amazon Textract to extract the text from the reports, and Amazon Comprehend Medical to identify the PHI from the extracted text, would be the most efficient solution as it would involve the least operational overhead. Textract is specifically designed for extracting text from documents, and Comprehend Medical is a fully managed service that can accurately identify PHI in medical text. This solution would require minimal maintenance and would not incur any additional costs beyond the usage fees for Textract and Comprehend Medical.
Comment: • Amazon Textract: This program is made to extract text and data from scanned documents, such as pictures and PDFs. It helps to retain the formatting of the report by automatically extracting text while preserving the document's layout. Identifying and extracting medical information, including protected health information (PHI), from unstructured text is the specialty of Amazon Comprehend Medical. Medical entities that are frequently included in reporting on healthcare, such as ailments, drugs, and more, can be recognized by it.
Comment: with the choices here, I would go with C, but if offered, I would use amazon textract for the text and use Macie to do the scanning of text files, not comprehend.
Comment: Here's why: Amazon Textract has built-in support to extract text from PDFs and images, eliminating the need to build this yourself with Python libraries. Amazon Comprehend Medical has pre-trained machine learning models to identify PHI entities out-of-the-box, avoiding the need to train your own SageMaker model. Using these fully managed AWS services minimizes operational overhead of maintaining machine learning models yourself.
Comment: Option C is the right answer.
Comment: C leverages capabilities of Textract, which is a service that automatically extracts text and data from documents, including PDF and JPEG. By using Textract, hospital can extract text content from reports without need for additional custom code or libraries. Once text is extracted, hospital can then use Comprehend Medical, a natural language processing service specifically designed for medical text, to analyze and identify PHI. It can recognize medical entities such as medical conditions, treatments, and patient information. A. suggests using existing Python libraries, which would require hospital to develop and maintain custom code for text extraction and PHI identification. B and D involve using Textract along with SageMaker or Rekognition, respectively, for PHI identification. While these options could work, they introduce additional complexity by incorporating machine learning models and training.
Comment: Key word: hospital!
Comment: Answer C:
Comment: Selected Answer: C Amazon Textract is a machine learning (ML) service that automatically extracts text, handwriting, and data from scanned documents.
Comment: Option C
Comment: WHY OPTION D IS WRONG
Comment: D is wrong only because Amazon Rekognition doesn't read text, only explicit image contents.
Comment: B/C you use TextTract to extract text not Rekognition.
Comment: Agreed
Comment: C is correct Textract- for extracting the text and Comprehend to identify the medical info https://aws.amazon.com/comprehend/medical/
Comment: i think C should be the answer here, > Immediate accessibility is always required as the files contain critical business data that is not easy to reproduce If they do not explicitly mention that they are using Glacier Instant Retrieval, we should assume that Glacier -> takes more time to retrieve and may not meet the requirements
Comment: You can make that assumption, but I think it would be wrong to make it. It does not state they are not using Glacier Instant Retrieval, and it's use would be the logical choice in this question, so I'm going for A
Comment: "With S3 Glacier Instant Retrieval, you can save up to 68% on storage costs compared to using the S3 Standard-Infrequent Access (S3 Standard-IA) storage class, when your data is accessed once per quarter." Repeat: once per quarter! Plus if you keep all the data forever, even if on Glacier, it will cost more over time, than storing on a higher-cost storage for a period of time (here: 4 yrs). A does not delete.
Comment: Sorry! A also deletes... My bad... Still. once a quarter.
Comment: I think his assumption is correct because if you go to AWS documentation (https://aws.amazon.com/s3/storage-classes/glacier/) they clearly mention: "S3 Glacier Flexible Retrieval (formerly S3 Glacier)". So since this question doesn't specify the S3 Glacier class, then it would default to flexible retrieval (which ofc is not equal to Instant Retrieval).
Comment: why everybody assumed files must be deleted after 4 years. they said files "can" be deleted, and not "must" be deleted. ideally store the files in glacier after 4 years
Comment: Because it requires the lowest cost
Comment: Yeah, Correct answer is C Because even if you assume the glacier class as Instant Retrieval. As per the Instant Retrieval class the immediate availability is only once per quarter. But in question it is clearly mentioned that the files should be immediately available anytime.
Comment: Most COST EFFECTIVE A: S3 Glacier Instant Retrieval is a new storage class that delivers the fastest access to archive storage, with the same low latency and high-throughput performance as the S3 Standard and S3 Standard-IA storage classes. You can save up to 68 percent on storage costs as compared with using the S3 Standard-IA storage class when you use the S3 Glacier Instant Retrieval storage class and pay a low price to retrieve data.
Comment: COST EFFECTIVE IS THE DIAL WORD HERE. Answer is A
Comment: Glacier has high retrieval costs and long retrieval times, which does not meet the requirement for immediate accessibility.
Comment: "Immediate accessibility is always required as the files contain critical business data that is not easy to reproduce" is the key sentence. answer is C.
Comment: But S3 Glacier Instant Retrieval "is designed for rarely accessed data that still needs immediate access in performance-sensitive use cases", so it offers lower cost and instant retrieval, so A
Comment: I agree with your key sentence..but the one zone infrequent doesn't fit for critical business and it is used for recreate..
Comment: Glaciers usually take some time to retrieve
Comment: *Immediate accessibility*
Comment: It should be C. The critical point is Immediate accessibility, only S3-IA can provide this.
Comment: "Immediate accessibility is always required". It can't be a, since Glacier Instant Retrieval has a limit of times the data can be accessed. "S3 Glacier Retrieval is the lowest cost archive storage with milliseconds retrieval for rarely accessed data. It is ideal for data that is accessed once or twice per quarter, and that requires immediate access."
Comment: If you do so more than ~4 times per year, you would pay more for Glacier Instant Retrieval than for S3 Standard.
Comment: immidiately accessible for 4 years bur rarely use - S3 standard IA. Correct answer is C
Comment: Keep in mind that "Glacier Flexible Retrieval" was previously named just "Glacier" (before they added Instant Retrieval). Regardless, they should have made it clear which Glacier class they are referring to since which one you select/assume can impact the correctness.
Comment: I am going to go with B. Reasoning = A = even if Glacier Instant Retrieval was used here, you can only use that quick retrieval once a quarter which isn't what the prompt is asking for. B - One Zone is the cheapest option, and the prompt does not ask for high availability. C / D - see reasoning for B
Comment: It does mention that the data is not easily reproducible, which implies HA, so that eliminates 1Z in this case.
Comment: S3 One Zone-Infrequent Access (S3 One Zone-IA) is cheaper than S3 Standard and S3 Standard-Infrequent Access (S3 Standard-IA) but still offers immediate accessibility. Since the files are rarely accessed after the first 30 days, transitioning them to S3 One Zone-IA after 30 days will reduce costs. The 4-year retention period aligns with the company policy, and after this period, the files can be deleted. Option C suggests moving the files from S3 Standard to S3 Standard-Infrequent Access (S3 Standard-IA) after 30 days, which is a more expensive storage class compared to S3 One Zone-Infrequent Access (S3 One Zone-IA). Since the files are rarely accessed after the first 30 days, moving them to S3 Standard-IA would result in higher storage costs compared to moving them to S3 One Zone-IA. Therefore, option B is more cost-effective than option C.
Comment: C is the correct answer
Comment: C: is good option because immediate accessibility is required
Comment: The question ask the MOST cost-effective solution "S3 One Zone-IA stores data in a single AZ and costs 20% less than S3 Standard-IA" https://aws.amazon.com/fr/s3/storage-classes/#:~:text=S3%20One%20Zone%2DIA%20is,less%20than%20S3%20Standard%2DIA.
Comment: correct
Comment: Ans -C It should be C, As Glacier always takes some time in retrieval until they say that they are using Glacier instant access retrieval service.
Comment: answer is c because glacier is not immediate thats why a is not the answer
Comment: Option C: Create an S3 bucket lifecycle policy to move files from S3 Standard to S3 Standard-Infrequent Access (S3 Standard-IA) 30 days from object creation. Delete the files 4 years after object creation. Options A, B, and D have drawbacks: Option A: Transitioning to S3 Glacier might introduce retrieval times and costs, which may not be suitable for files that require immediate accessibility. Deleting directly after 4 years is a more straightforward approach. Option B: S3 One Zone-Infrequent Access (S3 One Zone-IA) is less durable than Standard or Standard-Infrequent Access, as it stores data in a single availability zone. This may not be ideal for critical business data. Option D: Transitioning to S3 Glacier after 4 years introduces retrieval times and costs, which might not align with the immediate accessibility requirement. It adds complexity without a clear benefit in this scenario.
Comment: For immediate access Glacier https://aws.amazon.com/pm/s3-glacier/?gclid=CjwKCAiAt5euBhB9EiwAdkXWO0uogf9S1lc6VBWw8fX7arIx3P_Le4skMgzg_4QX0V5NEueI9ZtS5hoCN5kQAvD_BwE&trk=c8974be7-bc21-436d-8108-722e8ab912e1≻_channel=ps&ef_id=CjwKCAiAt5euBhB9EiwAdkXWO0uogf9S1lc6VBWw8fX7arIx3P_Le4skMgzg_4QX0V5NEueI9ZtS5hoCN5kQAvD_BwE:G:s&s_kwcid=AL!4422!3!674509851564!e!!g!!s3%20glacier!19574556914!153569363253
Comment: S3 glacier cannot provide immediate accessibility
Comment: In case of SQS - multi-consumers if one consumer has already picked the message and is processing, in meantime other consumer can pick it up and process the message there by two copies are added at the end. To avoid this the message is made invisible from the time its picked and deleted after processing. This visibility timeout is increased according to max time taken to process the message
Comment: To add to this "The VisibilityTimeout in SQS is a time frame that the message can be hidden so that no others can consume it except the first consumer who calls the ReceiveMessageAPI." The API ChangeMesssageVisibility changes this value.
Comment: To ensure that messages are being processed only once, a solutions architect should use the ChangeMessageVisibility API call to increase the visibility timeout which is Option D. The visibility timeout determines the amount of time that a message received from an SQS queue is hidden from other consumers while the message is being processed. If the processing of a message takes longer than the visibility timeout, the message will become visible to other consumers and may be processed again. By increasing the visibility timeout, the solutions architect can ensure that the message is not made visible to other consumers until the processing is complete and the message can be safely deleted from the queue. Option A (Use the CreateQueue API call to create a new queue) would not address the issue of duplicate message processing. Option B (Use the AddPermission API call to add appropriate permissions) is not relevant to this issue. Option C (Use the ReceiveMessage API call to set an appropriate wait time) is also not relevant to this issue.
Comment: not relevant to this issue. ??? what is added value
Comment: Option B (Use the AddPermission API call to add appropriate permissions) is not relevant to this issue because it deals with setting permissions for accessing an SQS queue, which is not related to preventing duplicate records in the RDS table. Option C (Use the ReceiveMessage API call to set an appropriate wait time) is not relevant to this issue because it is related to configuring how long the ReceiveMessage API call should wait for new messages to arrive in the SQS queue before returning an empty response. It does not address the issue of duplicate records in the RDS table.
Comment: Ans D - once the message is selected in the queue 'hide' it from other users/apps so it is only processed once, using API 'ChangeMesssageVisibility'
Comment: AB: Irrelevant C: This is for long polling not for execution https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling D: Visibility is correct fix issue because over here other SQS clients are seeing the same message back in the que when the previous processor is taking longer than expected to process the message
Comment: I also opt for D, but asking does increasing MessageVisibilityTimeOut good always?
Comment: This parameter is the timeout after which the SQS assumes that the processing has failed and makes the item visible to other que processors. It is normal to increase the timeout if it takes longer to process items.
Comment: Option D is the right answer.
Comment: The visibility timeout is the duration during which SQS prevents other consumers from receiving and processing the same message. By increasing the visibility timeout, you allow more time for the processing of a message to complete before it becomes visible to other consumers. Option A, creating a new queue, does not address the issue of concurrent processing and duplicate records. It would only create a new queue, which is not necessary for solving the problem. Option B, adding permissions, also does not directly address the issue of duplicate records. Permissions are necessary for accessing the SQS queue but not for preventing concurrent processing. Option C, setting an appropriate wait time using the ReceiveMessage API call, does not specifically prevent duplicate records. It can help manage the rate at which messages are received from the queue but does not address the issue of concurrent processing.
Comment: D is correct
Comment: Answer D: visibility timeout beings when amazon SQS return a message
Comment: D = ChangeMessageVisibility
Comment: In theory, between reception and changing visibility, you can have multiple consumers. Question is not good as it won't guarantee not executing twice.
Comment: Increaseing visibility timeout makes sure message is not visible for time taken to process the message.
Comment: Option D
Comment: D is correct
Comment: D is the correct choise, increasing the visibility timeout according to max time taken to process the message on the RDS.
Comment: True, it's D. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
Comment: Direct Connect + VPN best of both
Comment: Direct Connect goes throught 1 Gbps, 10 Gbps or 100 Gbps and the VPN goes up to 1.25 Gbps. https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-vpn.html
Comment: And A - as primary use Direct Connect to provide a solid connection. Company is not too worried about backup (other than it works) so use cheaper VPN Site-to-Site.
Comment: Ans A- Direct Connect because company needs consistent connection. As a back up, company wants cheaper solution so VPN Site to Site connection should be okay.
Comment: HA low latency + minimize cost + acceptable slow traffic if primary fails B: VPN tunnel will be slow C: 2 direct connect will be expensive D: Backup connection for what? A: Direct connect + VPN as a backup works
Comment: A highly available connection with consistent low latency = AWS Direct Connect Minimize costs and accept slower traffic if the primary connection fails = VPN connection
Comment: A is the right choice to save cost
Comment: Highly available connectivity using Direct Connect for consistent low latency and high throughput. Cost optimization by using a VPN as a slower, lower cost backup for when Direct Connect fails. Automatic failover to the VPN when Direct Connect fails.
Comment: A highly available connection with consistent low latency = AWS Direct Connect Minimize costs and accept slower traffic if the primary connection fails = VPN connection
Comment: Slower traffic when primary fails, so the backup plan needs a cheaper solution, and the primary requires high performance, so A.
Comment: Even though, there are a lots of variable affecting the cost of the connection, VPN connection is cheaper than the Direct Connect most of the time since VPN Connection doesn't require any dedicated physical circuit involved.
Comment: Option A is the right answer.
Comment: Options B and C propose using multiple VPN connections for private connectivity and as backups. While VPNs can serve as backups, they may not provide the same level of consistent low latency and high availability as Direct Connect connections. Additionally, provisioning multiple VPN tunnels can increase operational complexity and costs. Option D suggests using the Direct Connect failover attribute from the AWS CLI to automatically create a backup connection if the primary Direct Connect connection fails. While this approach can be automated, it does not provide the same level of immediate failover capabilities as having a separate backup connection in place. Therefore, option A, provisioning an AWS Direct Connect connection to a Region and provisioning a VPN connection as a backup, is the most suitable solution that meets the company's requirements for connectivity, cost-effectiveness, and high availability.
Comment: higly available - > direct connect beecause connection can go up to 10GBPs and VPN 1.5GBPs as backup
Comment: Option A is the correct solution to meet the requirements of the company. Provisioning an AWS Direct Connect connection to a Region will provide a private and dedicated connection with consistent low latency. As the company requires a highly available connection, a VPN connection can be provisioned as a backup if the primary Direct Connect connection fails. This approach will minimize costs and provide the required level of availability.
Comment: With AWS Direct Connect + VPN, you can combine AWS Direct Connect dedicated network connections with the Amazon VPC VPN. This solution combines the benefits of the end-to-end secure IPSec connection with low latency and increased bandwidth of the AWS Direct Connect to provide a more consistent network experience than internet-based VPN connections. https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-vpn.html
Comment: Why not B? Two VPNs on different connections? Direct Connect costs a fortune?
Comment: The company requires a highly available connection with consistent low latency to an AWS Region, this is provided by Direct Connect as primary connection. The company allows a slower connection only for the backup option, so A is the right answer
Comment: By configuring the Auto Scaling group to use multiple Availability Zones, the application will be able to continue running even if one Availability Zone goes down. Configuring the database as Multi-AZ will also ensure that the database remains available in the event of a failure in one Availability Zone. Using an Amazon RDS Proxy instance for the database will allow the application to automatically route traffic to healthy database instances, further increasing the availability of the application. This solution will meet the requirements for high availability with minimal operational effort.
Comment: RDS Proxy for Aurora https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: Ans B - good explanation by SilentMilli (1yr 8mth ago). The database Proxy is key.
Comment: Keyword - Higly available Use multiple availability zones
Comment: A: Different region doesn't help C: Would have made sense if it wasn't restricting to one AZ. D: Regions + S3 + Lambda = Operational effort extreme B: Although not entirely sure how RDS Proxy helps because it is for connection pooling but it is the only workable solution using multi AZ
Comment: One of the benefits of Amazon RDS Proxy is that it can improve application recovery time after database failovers. While RDS Proxy supports both MySQL as well as PostgreSQL engines, in this post, we will use a MySQL test workload to demonstrate how RDS Proxy reduces client recovery time after failover by up to 79% for Amazon Aurora MySQL and by up to 32% for Amazon RDS for MySQL. -> contributes to minimum downtime req
Comment: PS: https://aws.amazon.com/blogs/database/improving-application-availability-with-amazon-rds-proxy/
Comment: The company wants to minimize costs and is willing to accept slower traffic if the primary connection fails, it may be tempted to choose a VPN connection as a backup, in which case the answer is A. Cost-Effectiveness: VPN connections are generally more economical than AWS Direct Connect, especially for low to moderate bandwidth needs. Backup connection: A VPN connection can serve as a more cost-effective backup if the primary Direct Connect connection fails, even if it may be slower. Acceptance of slower traffic: The question clearly states that the company is willing to accept slower traffic if the primary connection fails, which implies a tolerance for connection speeds.
Comment: This is about the previous question ;)
Comment: ASG and MultiAZ is the best answer
Comment: B is the right answer
Comment: Option B requires the least operational effort to meet the high availability and minimum downtime/data loss requirements. The key points are: Use an Auto Scaling group across multiple AZs for high availability of the EC2 instances. Configure the Aurora DB as Multi-AZ for high availability, automatic failover, and minimum data loss. Use RDS Proxy for connection pooling to the DB for performance
Comment: Highly available, Minimum downtime and Minimum loss of data = Auto Scaling group on Multi-AZ, Database on Multi-AZ, Amazon RDS Proxy.
Comment: Option B is the right answer.
Comment: B is correct answer
Comment: A. This approach provides geographic redundancy, it introduces additional complexity and operational effort, including managing replication, handling latency, and potentially higher data transfer costs. C. While snapshots can be used for data backup and recovery, they do not provide real-time failover capabilities and can result in significant data loss if a failure occurs between snapshots. D. While this approach offers some decoupling and scalability benefits, it adds complexity to the data flow and introduces additional overhead for data processing. In comparison, option B provides a simpler and more streamlined solution by utilizing multiple AZs, Multi-AZ configuration for the database, and RDS Proxy for improved connection management. It ensures high availability, minimal downtime, and minimum loss of data with the least operational effort.
Comment: @Wajif the reason why it's not A is because the question mentions High availability and nothing to do with region. You can achieve HA without spanning multiple regions. Also B is incorrect because ALB are region specific and span across multiple AZ with that specific region (not cross region)
Comment: RDS Proxy is fully managed by AWS for RDS/Aurora. It is auto-scaling and highly available by default.
Comment: The correct solution is B: Configure the Auto Scaling group to use multiple Availability Zones. Configure the database as Multi-AZ. Configure an Amazon RDS Proxy instance for the database. This solution will meet the requirements of high availability with minimum downtime and minimum loss of data with the least operational effort. By configuring the Auto Scaling group to use multiple Availability Zones, the web application will be able to withstand the failure of one Availability Zone without any disruption to the service. By configuring the database as Multi-AZ, the database will automatically failover to a standby instance in a different Availability Zone in the event of a failure, ensuring minimal downtime. Additionally, using an RDS Proxy instance will help to improve the performance and scalability of the database.
Comment: Aurora PostgreSQL DB clusters don't support Aurora Replicas in different AWS Regions https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.html
Comment: I would choose A, as NLB supports HTTP and HTTPS Health Checks, BUT you can't put any URL (as proposed), only the node IP addresses. So, the solution is C.
Comment: can you elaborate more pls
Comment: NLBs support HTTP, HTTPS and TCP health checks: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html (check HealthCheckProtocol) But NLBs only accept either selecting EC2 instances or IP addresses directly as targets. You can't provide a URL to your endpoints, only a health check path (if you're using HTTP or HTTPS health checks).
Comment: What's the difference between endpoint URL and health check path?
Comment: A URL includes the hostname. The health check path is only the path portion. For example, URL = https://i-0123456789abcdef.us-west-2.compute.internal/index.html health check path= /index.html
Comment: Option C. NLB works at Layer 4 so it does not support HTTP/HTTPS. The replacement for the ALB is the best choice.
Comment: That's incorrect. NLB does support HTTP and HTTPS (and TCP) health checks. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html There just isn't an answer option that reflects that. My guess is that the question and/or answer options are outdated.
Comment: Ans C - Yup, somethings happening at the Application level so replace NLB with ALB
Comment: NLB is for network errors and low level traffic stuff ALB is for application so C is the only realistic option here
Comment: NLB does support HTTP/HTTPS Health Checks. I saw other people comments, it seems like the question were rephrased. The comments were highlighting "application URL", but I don't see words on the question.
Comment: You can use HTTP/HTTPS ONLY when Target is ALB. By default it is TCP. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html#health-check-settings HealthCheckProtocol The protocol the load balancer uses when performing health checks on targets. The possible protocols are HTTP, HTTPS, and TCP. The default is the TCP protocol. If the target type is ALB, the supported health check protocols are HTTP and HTTPS.
Comment: ALB allows you to specify the path which helps to check the error. NLB cannot do that.
Comment: The key points are: Use an Application Load Balancer (ALB) instead of a Network Load Balancer (NLB) since ALBs support HTTP health checks. Configure HTTP health checks on the ALB to monitor the application health. Use an Auto Scaling action triggered by the ALB health checks to automatically replace unhealthy instances.
Comment: Option C is the right answer.
Comment: A. NLB, but NLB's health checks are designed for TCP/UDP protocols and lack the advanced features specific to HTTP applications provided by ALB. B. This approach involves custom scripting and manual intervention, which contradicts the requirement of not writing custom scripts or code. D. Since the NLB does not detect HTTP errors, relying solely on the UnhealthyHostCount metric may not accurately capture the health of the application instances. Therefore, C is the recommended choice for improving the application's availability without custom scripting or code. By replacing the NLB with an ALB, enabling HTTP health checks, and configuring Auto Scaling to replace unhealthy instances, the company can ensure that only healthy instances are serving traffic, enhancing the application's availability automatically.
Comment: Replace the NLB (layer 4 udp and tcp) with an Application Load Balancer - ALB (layer 7) supports http and https requests.
Comment: must be C Application availability: NLB cannot assure the availability of the application. This is because it bases its decisions solely on network and TCP-layer variables and has no awareness of the application at all. Generally, NLB determines availability based on the ability of a server to respond to ICMP ping or to correctly complete the three-way TCP handshake. ALB goes much deeper and is capable of determining availability based on not only a successful HTTP GET of a particular page but also the verification that the content is as was expected based on the input parameters.
Comment: Also A doesn't offer what bellow in C offers... Configure an Auto Scaling action to replace unhealthy instances
Comment: Answer is C A solution architect can use Amazon EC2 Auto Scaling health checks to automatically detect and replace unhealthy instances in the EC2 Auto Scaling group. The health checks can be configured to check the HTTP errors returned by the application and terminate the unhealthy instances. This will ensure that the application's availability is improved, without requiring custom scripts or code.
Comment: I will go with A as Network load balancer supports HTTP and HTTPS health checks, maybe the answer is outdated.
Comment: But you'd need to check the health of the individual nodes, NOT "the URL of the company's application" which points to the Load Balancer.
Comment: https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4 As NLB does not support HTTP health checks, you can only use ALB to do so.
Comment: That's incorrect. NLB does support HTTP and HTTPS (and TCP) health checks. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html Just a general tip: Medium is not a reliable resource. Anyone can create content there. Rely only on official AWS documentation.
Comment: But you'd need to check the health of the individual nodes, NOT "the URL of the company's application" which points to the Load Balancer (as mentioned in A).
Comment: Answer is C, and A is wrong because In NLB, for HTTP or HTTPS health check requests, the host header contains the IP address of the load balancer node and the listener port, not the IP address of the target and the health check port. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html
Comment: Correct answer - C Network load balancers (Layer 4) allow to: • Forward TCP & UDP traffic to your instances • Handle millions of request per seconds • Less latency ~100 ms (vs 400 ms for ALB) Best choice for HTTP traffic - replace to Application load balancer
Comment: A - DynamoDB global tables provides multi-Region, and multi-active database, but it not valid "in case of data corruption". In this case, you need a backup. This solutions isn't valid. **B** - Point in Time Recovery is designed as a continuous backup juts to recover it fast. It covers perfectly the RPO, and probably the RTO. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html C - A daily export will not cover the RPO of 15min. D - DynamoDB is serverless... so what are these EBS snapshots taken from???
Comment: Yes, it is possible to take EBS snapshots of a DynamoDB table. The process for doing this involves the following steps: Create a new Amazon Elastic Block Store (EBS) volume from the DynamoDB table. Stop the DynamoDB service on the instance. Detach the EBS volume from the instance. Create a snapshot of the EBS volume. Reattach the EBS volume to the instance. Start the DynamoDB service on the instance. You can also use AWS Data pipeline to automate the above process and schedule regular snapshots of your DynamoDB table. Note that, if your table is large and you want to take a snapshot of it, it could take a long time and consume a lot of bandwidth, so it's recommended to use the Global Tables feature from DynamoDB in order to have a Multi-region and Multi-master DynamoDB table, and you can snapshot each region separately.
Comment: What is "DynamoDB service on the instance" ?
Comment: DynamoDB is a native cloud service, there is no "instance" that you could "stop", or detach an "EBS volume" from.
Comment: The best solution to meet the RPO and RTO requirements would be to use DynamoDB point-in-time recovery (PITR). This feature allows you to restore your DynamoDB table to any point in time within the last 35 days, with a granularity of seconds. To recover data within a 15-minute RPO, you would simply restore the table to the desired point in time within the last 35 days. To meet the RTO requirement of 1 hour, you can use the DynamoDB console, AWS CLI, or the AWS SDKs to enable PITR on your table. Once enabled, PITR continuously captures point-in-time copies of your table data in an S3 bucket. You can then use these point-in-time copies to restore your table to any point in time within the retention period. ***CORRECT*** Option B. Configure DynamoDB point-in-time recovery. For RPO recovery, restore to the desired point in time.
Comment: ***WRONG*** Option A (configuring DynamoDB global tables) would not meet the RPO requirement, as global tables are designed to replicate data to multiple regions for high availability, but they do not provide a way to restore data to a specific point in time. Option C (exporting data to S3 Glacier) would not meet the RPO or RTO requirements, as S3 Glacier is a cold storage service with a retrieval time of several hours. Option D (scheduling EBS snapshots) would not meet the RPO requirement, as EBS snapshots are taken on a schedule, rather than continuously. Additionally, restoring a DynamoDB table from an EBS snapshot can take longer than 1 hour, so it would not meet the RTO requirement.
Comment: Ans B - just use the built-in DynamoDB PITR... simples...
Comment: With point-in-time recovery, you can restore that table to any point in time during the last 35 days. After you enable point-in-time recovery, you can restore to any point in time from five minutes before the current time until 35 days ago. DynamoDB maintains incremental backups of your table.
Comment: A: Scalability across regions which is not required C: Glacier exports and backup restore won't meet 1 hour RPO time D EBS for DynamoDB table? Sounds impractical B: DynamoDB point-in-time recovery is for this scenario. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html
Comment: The best option to meet the RPO of 15 minutes and RTO of 1 hour is B) Configure DynamoDB point-in-time recovery. For RPO recovery, restore to the desired point in time. The key points: DynamoDB point-in-time recovery can restore to any point in time within the last 35 days. This supports an RPO of 15 minutes. Restoring from a point-in-time backup meets the 1 hour RTO. Point-in-time recovery is specifically designed to restore DynamoDB tables with second-level granularity.
Comment: A. Global tables provide multi-region replication for disaster recovery purposes, they may not meet the desired RPO of 15 minutes without additional configuration and potential data loss. C. Exporting and importing data on a daily basis does not align with the desired RPO of 15 minutes. D. EBS snapshots can be used for data backup, they are not directly applicable to DynamoDB and cannot provide the desired RPO and RTO without custom implementation. In comparison, option B utilizing DynamoDB's built-in point-in-time recovery functionality provides the most straightforward and effective solution for meeting the specified RPO of 15 minutes and RTO of 1 hour. By enabling PITR and restoring the table to the desired point in time, the company can recover the customer information with minimal data loss and within the required time frame.
Comment: The answer is in the question. Read the question again!!! Option B. Configure DynamoDB point-in-time recovery. For RPO recovery, restore to the desired point in time.
Comment: If there is anyone who is willing to share his/her contributor access, then please write to[email protected]
Comment: Option B
Comment: B is correct DynamoDB point-in-time recovery allows the solutions architect to recover the DynamoDB table to a specific point in time, which would meet the RPO of 15 minutes. This feature also provides an RTO of 1 hour, which is the desired recovery time objective for the application. Additionally, configuring DynamoDB point-in-time recovery does not require any additional infrastructure or operational effort, making it the best solution for this scenario. Option D is not correct because scheduling Amazon EBS snapshots for the DynamoDB table every 15 minutes would not meet the RPO or RTO requirements. While EBS snapshots can be used to recover data from a DynamoDB table, they are not designed to provide real-time data protection or recovery capabilities
Comment: B is correct
Comment: B is the answer
Comment: I think DynamoDB global tables also work here, but Point in Time Recovery is a better choice
Comment: I THINK B. https://dynobase.dev/dynamodb-point-in-time-recovery/
Comment: answer is D
Comment: DynamoDB is serverless, so no storage snapshots available. https://aws.amazon.com/dynamodb/
Comment: ***CORRECT*** The correct answer is Option D. Deploy an S3 VPC gateway endpoint into the VPC and attach an endpoint policy that allows access to the S3 buckets. By deploying an S3 VPC gateway endpoint, the application can access the S3 buckets over a private network connection within the VPC, eliminating the need for data transfer over the internet. This can help reduce data transfer fees as well as improve the performance of the application. The endpoint policy can be used to specify which S3 buckets the application has access to.
Comment: ***WRONG*** Option A, deploying Amazon API Gateway into a public subnet and adjusting the route table, would not address the issue of data transfer fees as the application would still be transferring data over the internet. Option B, deploying a NAT gateway into a public subnet and attaching an endpoint policy, would not address the issue of data transfer fees either as the NAT gateway is used to enable outbound internet access for instances in a private subnet, rather than for connecting to S3. Option C, deploying the application into a public subnet and allowing it to route through an internet gateway, would not reduce data transfer fees as the application would still be transferring data over the internet.
Comment: To reduce costs get rid of NAT Gateway , VPC endpoint to S3
Comment: Ans D - remove the internet connection by using a more efficient private VPC direct to S3
Comment: S3 VPC Gateway is the cheapest solution as it does not use any billable traffic within same region
Comment: Prevent traffic from traversing the internet = Gateway VPC endpoint for S3.
Comment: The best solution to reduce data transfer costs for an application frequently accessing S3 buckets in the same region is option D - Deploy an S3 VPC gateway endpoint into the VPC and attach an endpoint policy that allows access to the S3 buckets. The key points: - S3 gateway endpoints allow private connections between VPCs and S3 without going over the public internet. - This avoids data transfer fees for traffic between the VPC and S3 within the same region. - An endpoint policy controls access to specific S3 buckets.
Comment: A. API Gateway can serve as a proxy for S3 requests, it adds unnecessary complexity and additional costs compared to a direct VPC endpoint. B. Using a NAT gateway for accessing S3 introduces unnecessary data transfer costs as traffic would still flow over the internet. C. This approach would incur data transfer fees as the traffic would go through the public internet. In comparison, option D using an S3 VPC gateway endpoint provides a direct and cost-effective solution for accessing S3 buckets within the same Region. By keeping the data transfer within the AWS network infrastructure, it helps reduce data transfer fees and provides secure access to the S3 resources.
Comment: Option D is correct answer.
Comment: To answer this question, I need to know the comparison of the types of gateway of costs, please give me a tip about that issue.
Comment: Option D
Comment: The answer is D:- Actually, the Application (EC2) is running in the same region...instead of going to the internet, data can be copied through the VPC endpoint...so there will be no cost because data is not leaving the AWS infra
Comment: Can somebody please explain this question? Are we assuming the application is running in AWS and that adding the gateway endpoint avoids the need for the EC2 instance to access the internet and thus avoid costs? Thanks a lot.
Comment: Yes correct
Comment: D is correct
Comment: Selected Answer: D FYI : -There is no additional charge for using gateway endpoints. -Interface endpoints are priced at ~ $0.01/per AZ/per hour. Cost depends on the Region - S3 Interface Endpoints resolve to private VPC IP addresses and are routable from outside the VPC (e.g via VPN, Direct Connect, Transit Gateway, etc). S3 Gateway Endpoints use public IP ranges and are only routable from resources within the VPC.
Comment: Close question to the Question #4, with same solution.
Comment: C because from on-prem network to bastion through internet (using on-prem resource's public IP), D because bastion and ec2 is in same VPC, meaning bastion can communicate to EC2 via it's private IP address
Comment: on-prem -----> bastion host (we use internet, means that we need external IPs of the company) bastion host -----> private subnet (we use private IP since we are in the same AWS network)
Comment: Ans C,D - as per Six_Fingered_Jose (1 year, 10 mth ago)
Comment: CD - easy
Comment: I've noticed that it is very important to focus on the logic for the solution, not just services. For example, in this question, the goal is to access the application instances only from the bastion while keeping them in the private subnet, which already suggests that the SSH connection must be allowed for the bastion private IP. This is answer D. On the other hand, the bastion must accept connections only from the company's premises, which already eliminates option A. Option B is wrong because internal IP is used only internally; in this case, the connection will be through the internet, which means that it must be the external IP; therefore, answer C.
Comment: C: Bastion in public subnet should only allow access from public IP of the company D: app instance in private subnet should only allow access from bastion ABD are wrong choices Here is a working example on AWS docs if you want to learn about Bastion setup https://aws.amazon.com/solutions/implementations/linux-bastion/
Comment: Good way to remember this one is to think of movie scene where someone is visiting a prisoner in a prison and talks to them from behind a glass using a 2 way phone. Visitor is in company Visitor area is public subnet Prisoner area is private subnet Phone is bastion Visitor (company) must only be allowed to use the phone (bastion) from the public area (public subnet) and the phone (bastion) must only be allowed to talk to the prisoner in the prisoner area (private subnet)
Comment: really good explanation!!!
Comment: the question mentioned from on-prem network to bastion through the company's internet then it should use the internal IP range not external ip ranges. so BD
Comment: How would you know the internal IP range of the company? B is wrong.
Comment: https://en.wikipedia.org/wiki/Network_address_translation That`s the reason is C and not B
Comment: Company's internet is internet - unless its company's intranet
Comment: Why are there always such unclear questions?
Comment: Key: through the company's internet connection
Comment: Option B - inbound access from the internal IP range for the company. This step ensures that only internal IP addresses from your company's network can access the bastion host, enhancing securit and then Option D
Comment: Please check first comments from top of them: Help2023 WherecanIstart Buruguduystunstugudunstuy
Comment: Allows inbound access from the external IP range for the company. Then allow inbound SSH access from only the private IP address of the bastion host.
Comment: C. This will restrict access to the bastion host from the specific IP range of the on-premises network, ensuring secure connectivity. This step ensures that only authorized users from the on-premises network can access the bastion host. D. This step enables SSH connectivity from the bastion host to the application instances in the private subnet. By allowing inbound SSH access only from the private IP address of the bastion host, you ensure that SSH access is restricted to the bastion host only.
Comment: the internal and external IP range is not clear
Comment: yes same for me
Comment: The admin is supposed to use "the company's Internet connection", NOT a VPN tunnel or DirectConnect. Thus the connection originates from the company's public/external IP.
Comment: The private/public IP address thing is confusing. Ideally, the private instances inbound rule would just allow traffic from the security group of the bastion host.
Comment: Why external and not internal?
Comment: Because the traffic goes through the public internet. In the public internet, public IP(external IP) is used.
Comment: Application is in private subnet Bastion Host is in public subnet D does not make sense because the bastion host is in public subnet and they don't have a private IP but only a public IP address attached to them. The IP wanting to connect is Public as well. Bastion host in public subnet allows external IP (via internet) of the company to access it. Which than leaves us to give permission to the application private subnet and for that the private subnet with the application accepts the IP coming from Bastion Host by changing its SG. C&E
Comment: Bastion host in public subnet because it has a public IP and a NAT Gateway that can route traffic out of your AWS VPC but it does have the ability to access the private subnet using private IP since it's not leaving AWS to access the private subnet. So C&D are the right answers.
Comment: You are right E is also fine but its not a best thing to do Using private IP is always better than using public IP unless the situation demands the use of Public IP.
Comment: Web Server Rules: Inbound traffic from 443 (HTTPS) Source 0.0.0.0/0 - Allows inbound HTTPS access from any IPv4 address Database Rules : 1433 (MS SQL)The default port to access a Microsoft SQL Server database, for example, on an Amazon RDS instance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html
Comment: EC2 web on public subnets + EC2 SQL on private subnet + security is high priority. So, Option A to allow HTTPS from everywhere. Plus option C to allow SQL connection from the web instance.
Comment: Ans A, C - allow public access for all input, but control access to database: source 0.0.0.0/0, control access on port 1433 (MS SQL)
Comment: SG are blocked by default and stateful so A: Allows inbound traffic from web to the HTTPS default port on web servers B: Outbound is not required if inbound is configured due to stateful nature of SG C: 1433 is SQL default so allow access from web-tier only D: Opens up the database to web on 1433 port E: opens up 443 port unnecessarily on the DB tier so less secure AC is the most secure config
Comment: Allow inbound traffic on port 443 from 0.0.0.0/0 on the web tier. Then allow inbound traffic on port 1433 from the security group for the web tier on the database tier.
Comment: The security group for the web tier should allow inbound traffic on port 443 from 0.0.0.0/0. This will allow clients to connect to the web tier using HTTPS. The security group for the web tier should also allow outbound traffic on port 443 to 0.0.0.0/0. This will allow the web tier to connect to the internet to download updates and other resources. The security group for the database tier should allow inbound traffic on port 1433 from the security group for the web tier. This will allow the web tier to connect to the database tier to access data. The security group for the database tier should not allow outbound traffic on ports 443 and 1433 to the security group for the web tier. This will prevent the database tier from being exposed to the public internet.
Comment: A. This configuration allows external users to access the web tier over HTTPS (port 443). However, it's important to note that it is generally recommended to restrict the source IP range to a more specific range rather than allowing access from 0.0.0.0/0 (anywhere). This would limit access to only trusted sources. C. By allowing inbound traffic on port 1433 (default port for Microsoft SQL Server) from the security group associated with the web tier, you ensure that the database tier can only be accessed by the EC2 instances in the web tier. This provides a level of isolation and restricts direct access to the database tier from external sources.
Comment: DB tier: Port 1433 is the known standard for SQL server and should be used. web tier on port 443 (HTTPS)
Comment: AC is correct
Comment: A & C are the correct answer. Inbound traffic to the web tier on port 443 (HTTPS) The web tier will then access the Database tier on port 1433 - inbound.
Comment: AC 443-http inbound and 1433-sql server Security group => focus on inbound traffic since by default outboud traffic is allowed
Comment: Security group => focus on inbound traffic since by default outboud traffic is allowed
Comment: why both are inbound rules
Comment: Because security groups are stateful.
Comment: ***CORRECT*** The correct answers are C and E. For security purposes, it is best practice to limit inbound and outbound traffic as much as possible. In this case, the web tier should only be able to access the database tier and not the other way around. Therefore, the security group for the web tier should only allow outbound traffic to the security group for the database tier on the necessary ports. Similarly, the security group for the database tier should only allow inbound traffic from the security group for the web tier on the necessary ports. Answer C: Configure the security group for the database tier to allow inbound traffic on port 1433 from the security group for the web tier. This is correct because the web tier needs to be able to connect to the database on port 1433 in order to access the data.
Comment: Answer E: Configure the security group for the database tier to allow inbound traffic on ports 443 and 1433 from the security group for the web tier. This is correct because the web tier needs to be able to connect to the database on both port 443 and 1433 in order to access the data. ***WRONG*** Answer A: Configure the security group for the web tier to allow inbound traffic on port 443 from 0.0.0.0/0. This is not correct because the web tier should not allow inbound traffic from the internet. Instead, it should only allow outbound traffic to the security group for the database tier.
Comment: ***WRONG*** Answer B: Configure the security group for the web tier to allow outbound traffic on port 443 from 0.0.0.0/0. This is not correct because the web tier should not allow outbound traffic to the internet. Instead, it should only allow outbound traffic to the security group for the database tier. Answer D: Configure the security group for the database tier to allow outbound traffic on ports 443 and 1433 to the security group for the web tier. This is not correct because the database tier should not allow outbound traffic to the web tier. Instead, it should only allow inbound traffic from the security group for the web tier on the necessary ports.
Comment: Chatgpt is unreliable this answer from same.
Comment: "The web tier needs to be able to connect to the database on both port 443 and 1433 in order to access the data" -> Nonsense, SQL Server needs only tcp/1433. Or tcp/1433 + udp/1433 plus the instance port if you have multiple instances. But you NEVER need tcp/443 to access SQL Server.
Comment: This is WRONG. Browse to a website and type :443 at the end of it. IT will translate to HTTPS. HTTPS = 443. answers are A and C
Comment: A and C
Comment: A and C
Comment: Agree with AC.
Comment: Agree with A>>> Lambda = serverless + autoscale (modernize), SQS= decouple (no more drops)
Comment: The catch phrase is "scale up when communication failures are detected" Scaling should not be based on communication failures, that'll be crying over spilled milk ! or rather too late. So D is wrong.
Comment: Spot on
Comment: it says "one tier becomes overloaded" , Not communication failure...
Comment: D says: "Use Amazon CloudWatch to monitor the SQS queue length and scale up when communication failures are detected".
Comment: Ans A - keep it simple: API Gateway + Lambda + SQS D won't work: it relies upon a failure detected - by then its too late)
Comment: The answer choice D cannot be the answer because CloudWatch is not an appropriate way to monitor transaction failures. I would have been more confused about it if CloudWatch hadn't been mentioned.
Comment: RESTful services = API Gateways https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html
Comment: Least operational overhead = API Gateway + Lambda + SQS BC wrong applications D: Will work but more operational overhead than A with less resilience to failures
Comment: You want to "modernize the application", that a modern application is serverless, in any case a modern application does NOT use EC2 instances. Also, managing EC2 instances (with the OS etc pp) is NOT "operationally efficient". Thus not D.
Comment: For me the solution could be based on using SNS with multiple topics to organize communication between different tiers ( Using Subscriber for one and Producer for another topic to proceed with transactions over multi-tiers ). CloudWatch to monitor SNS topics queue length and scale up/down based on counts of messages (NumberOfMessagesPublished)
Comment: The question asks for the most operationally efficient solution. The answer A is serverless, while the answer C is VM-based. There is no scenario where managin VMs is operationally more efficient than going serverless. If Operational Efficiency is what you look for, then you should always consider going serverless.
Comment: Wouldn't the scaling take some time? If there is queue length, then one tier IS already overloaded.
Comment: A is the perfect answer no need for the ASG
Comment: D is better because in answer A there is a bottleneck on a SQS - service app, D is as operationally efficient as A and solves the above issue
Comment: ASG is not as efficient as Lambda!
Comment: I feel the answer is D, Lambda would increase the complexity and overhead and it has limitation of running for 15 min.
Comment: How would Lambda increase the operational (!) complexity over handling and scaling servers (and their operating systems and patches etc.) on EC2?
Comment: MOST operationally efficient = Serverless = AWS Lambda functions, Amazon Simple Queue Service
Comment: A and D are both good solution however A will suffice the requirement as it is the most operational efficient for modern applications, AWS Lambda will scale elastically when application will become overloaded and the fact that it is serverless. SQS will handle the queue as well..
Comment: This solution addresses the issue of dropped transactions by decoupling the communication between application tiers using SQS. It ensures that transactions are not lost even if one tier becomes overloaded. By using EC2 in ASG, the application can automatically scale based on the demand and the length of the SQS. This allows for efficient utilization of resources and ensures that the application can handle increased workload and communication failures. CloudWatch is used to monitor the length of SQS. When queue length exceeds a certain threshold, indicating potential communication failures, the ASG can be configured to scale up by adding more instances to handle the load. D. This solution utilizes Lambda and API Gateway, which can be a valid approach for building serverless applications. However, it may introduce additional complexity and operational overhead compared to the requirement of modernizing an existing multi-tiered application.
Comment: Supposing the solution is D), what is the point of monitoring the SQS queue length if then the system scales up when communication failures are detected? Why not monitoring the amount of failures? Is it ok to assume that when the queue grows the system is failing? What is the system is under more demand? So, my guess, the solution is A)
Comment: ANS: A Key word - RESTful services - Amazon API Gateway
Comment: Must be D : Please refer to thread https://pupuweb.com/aws-saa-c02-actual-exam-question-answer-dumps-3/6/
Comment: DMS is for databases and here refers to “JSON files”. Public internet is not reliable. So best option is B.
Comment: ***CORRECT*** The most reliable solution for transferring the data in a secure manner would be option B: AWS DataSync over AWS Direct Connect. AWS DataSync is a data transfer service that uses network optimization techniques to transfer data efficiently and securely between on-premises storage systems and Amazon S3 or other storage targets. When used over AWS Direct Connect, DataSync can provide a dedicated and secure network connection between your on-premises data center and AWS. This can help to ensure a more reliable and secure data transfer compared to using the public internet.
Comment: ***WRONG*** Option A, AWS DataSync over the public internet, is not as reliable as using Direct Connect, as it can be subject to potential network issues or congestion. Option C, AWS Database Migration Service (DMS) over the public internet, is not a suitable solution for transferring large amounts of data, as it is designed for migrating databases rather than transferring large amounts of data from a storage area network (SAN). Option D, AWS DMS over AWS Direct Connect, is also not a suitable solution, as it is designed for migrating databases and may not be efficient for transferring large amounts of data from a SAN.
Comment: explanation about D option is good
Comment: Ans B - keep it simple... private netwk + direct connection
Comment: near-real-time + large data + secure = DataSync over DirectConnect A: Less secure due to public internet C: Slow and not secure D: Slow even if more secure DC may not even work as we don't know if there is a DB on other side but even if it was there, it is less preferred way
Comment: Any DMS related-service will not be efficient because DMS can only process JSON files UPTO 2 MB in size https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.html so B is CORRECT
Comment: AWS DataSync is a data transfer service that uses network optimization techniques to transfer data efficiently and securely between on-premises storage systems and Amazon S3 or other storage targets. When used over AWS Direct Connect, DataSync can provide a dedicated and secure network connection between your on-premises data center and AWS. This can help to ensure a more reliable and secure data transfer compared to using the public internet.
Comment: Secure and Most reliable transfer = AWS DataSync over AWS Direct Connect
Comment: AWS DataSync is designed for large scale, high speed data transfer between on-prem and S3. Using AWS Direct Connect provides a dedicated, private connection for reliable, consistent data transfer. DataSync seamlessly handles data replication, encryption, recovery etc.
Comment: Not over public hence AC out / DMS is for databases and here refers to “JSON files”.
Comment: DataSync is a service specifically designed for data transfer and synchronization between on-premises storage systems and AWS storage services like S3. It provides reliable and efficient data transfer capabilities, ensuring the secure movement of large volumes of data. By leveraging Direct Connect, which establishes a dedicated network connection between the on-premises data center and AWS, the data transfer is conducted over a private and dedicated network link. This approach offers increased reliability, lower latency, and consistent network performance compared to transferring data over the public internet. Database Migration Service is primarily focused on database migration and replication, and it may not be the most appropriate tool for general-purpose data transfer like JSON files. Transferring data over the public internet may introduce potential security risks and performance variability due to factors like network congestion, latency, and potential interruptions.
Comment: Best option and correct is B
Comment: as Ariel suggested and rightly so.....DMS is for databases and here refers to “JSON files”. Public internet is not reliable. so B
Comment: Option B
Comment: Option B. DMS is not needed as there is no Database migration requirement.
Comment: Public internet options automatically out being best-effort. DMS is for database migration service and here they have to just transfer the data to S3. Hence B.
Comment: B is correct
Comment: B - A SAN presents storage devices to a host such that the storage appears to be locally attached. ( NFS is, or can be, a SAN - https://serverfault.com/questions/499185/is-san-storage-better-than-nfs ) - AWS Direct Connect does not encrypt your traffic that is in transit by default. But the connection is private (https://docs.aws.amazon.com/directconnect/latest/UserGuide/encryption-in-transit.html)
Comment: (A) - You don't need to deploy an EC2 instance to host an API - Operational overhead (B) - Same as A (**C**) - Is the answer (D) - AWS Glue gets data from S3, not from API GW. AWS Glue could do ETL by itself, so don't need lambda. Non sense. https://aws.amazon.com/glue/
Comment: I don''t understand is why we should use Lambda in between to transform data. To me, Kinesis data firehose is enough as it is an extract, transform, and load (ETL) service.
Comment: It is because they assume that Kinesis Data Firehose built-in transformations are not enough. So you have to use specific lambda transformation. Please refer to this link : https://aws.amazon.com/kinesis/data-firehose/#:~:text=Amazon%20Kinesis%20Data%20Firehose%20is,data%20stores%2C%20and%20analytics%20services.
Comment: The company needs an API = Amazon API Gateway API A real-time data ingestion = Amazon Kinesis data stream A process that transforms data = AWS Lambda functions Kinesis Data Firehose delivery stream to send the data to Amazon S3 A storage solution for the data = Amazon S3
Comment: Ans C - the API is given so just configure Kinesis stream/Firehouse to use it
Comment: C is least operational overhead A: EC2 is overhead in this scenario B: Same as A D: Glue is not real time data streaming
Comment: It looks overengineered, but as it works, let's go for the C
Comment: The company needs an API = Amazon API Gateway API A real-time data ingestion = Amazon Kinesis data stream A process that transforms data = AWS Lambda functions Kinesis Data Firehose delivery stream to send the data to Amazon S3 A storage solution for the data = Amazon S3
Comment: "a real-time data ingestion" isn't firehose not realtime ? Kinesis FireHose is "Near" Real-time . It has 60 seconds gap. I think it should be D
Comment: The real-time part (data ingestion) will be performed by Kinesis Data Stream and API Gateway. After this, the transformation and storage of the data don't need to be in real-time, since it was already ingested, so Kinesis Firehose + Lambda is perfect. C makes sense to me.
Comment: Option C provides the least operational overhead to meet the requirements: API Gateway provides the API Kinesis Data Streams ingests the real-time data Lambda functions transform the data Firehose delivers the data to S3 storage The key advantages are: Serverless architecture requires minimal operational overhead Fully managed ingestion, processing and storage services No need to manage EC2 instances
Comment: Requirements: API- API gateway Real time data ingestion - AWS Kinesis data stream ETL(Extract Transform Load) - Kinesis Firehose Storage- S3
Comment: C - is the answer
Comment: C. By leveraging these services together, you can achieve a real-time data ingestion architecture with minimal operational overhead. The data flows from the API Gateway to the Kinesis data stream, undergoes transformations with Lambda, and is then sent to S3 via the Kinesis Data Firehose delivery stream for storage. A. This adds operational overhead as you need to handle EC2 management, scaling, and maintenance. It is less efficient compared to using a serverless solution like API Gateway. B. It requires deploying and managing an EC2 to host the API and configuring Glue. This adds operational overhead, including EC2 management and potential scalability limitations. D. It still requires managing and configuring Glue, which adds operational overhead. Additionally, it may not be the most efficient solution as Glue is primarily used for ETL scenarios, and in this case, real-time data transformation is required.
Comment: I am gonna choose D for this. Kinesis Data Stream + Data Firehose will adds up to the operational overhead, plus it is "Near real-time", not a real time solution. Lambda functions scale automatically, so no management of scaling/compute resources is needed. AWS Glue handles the data storage in S3, so no management of that is needed.
Comment: Gotta love all those chatgpt answers y'all are throwing at us. Kinesis Firehose is NEAR real-time, not real-time like your bots tell you.
Comment: Stem is about "real-time data INGESTION", not real-time processing.
Comment: option C is the best solution. It uses Amazon Kinesis Data Firehose which is a fully managed service for delivering real-time streaming data to destinations such as Amazon S3. This service requires less operational overhead as compared to option A, B, and D. Additionally, it also uses Amazon API Gateway which is a fully managed service for creating, deploying, and managing APIs. These services help in reducing the operational overhead and automating the data ingestion process.
Comment: Option C is the solution that meets the requirements with the least operational overhead. In Option C, you can use Amazon API Gateway as a fully managed service to create, publish, maintain, monitor, and secure APIs. This means that you don't have to worry about the operational overhead of deploying and maintaining an EC2 instance to host the API. Option C also uses Amazon Kinesis Data Firehose, which is a fully managed service for delivering real-time streaming data to destinations such as Amazon S3. With Kinesis Data Firehose, you don't have to worry about the operational overhead of setting up and maintaining a data ingestion infrastructure.
Comment: Finally, Option C uses AWS Lambda, which is a fully managed service for running code in response to events. With AWS Lambda, you don't have to worry about the operational overhead of setting up and maintaining a server to run the data transformation code. Overall, Option C provides a fully managed solution for real-time data ingestion with minimal operational overhead.
Comment: Option A is incorrect because it involves deploying an EC2 instance to host an API, which adds operational overhead in the form of maintaining and securing the instance. Option B is incorrect because it involves deploying an EC2 instance to host an API and disabling source/destination checking on the instance. Disabling source/destination checking can make the instance vulnerable to attacks, which adds operational overhead in the form of securing the instance.
Comment: Option D is incorrect because it involves using AWS Glue to send the data to Amazon S3, which adds operational overhead in the form of maintaining and securing the AWS Glue infrastructure. Overall, Option C is the best choice because it uses fully managed services for the API, data transformation, and data delivery, which minimizes operational overhead.
Comment: Option C
Comment: Option C
Comment: Answer is B "Amazon DynamoDB offers two types of backups: point-in-time recovery (PITR) and on-demand backups. (==> D is not the answer) PITR is used to recover your table to any point in time in a rolling 35 day window, which is used to help customers mitigate accidental deletes or writes to their tables from bad code, malicious access, or user error. (==> A isn't the answer) On demand backups are designed for long-term archiving and retention, which is typically used to help customers meet compliance and regulatory requirements. This is the second of a series of two blog posts about using AWS Backup to set up scheduled on-demand backups for Amazon DynamoDB. Part 1 presents the steps to set up a scheduled backup for DynamoDB tables from the AWS Management Console." (==> Not the DynamoBD console and C isn't the answer either) https://aws.amazon.com/blogs/database/part-2-set-up-scheduled-backups-for-amazon-dynamodb-using-aws-backup/
Comment: I think the answer is C because of storage time.
Comment: Dynamo backups cannot be scheduled or sent to S3, so answer should be B) 1) https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html 2) https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Backup.Tutorial.html
Comment: In the very same link you shared it says that you CAN send backups to S3 https://youtu.be/4INEu_hw30Q?t=54
Comment: The most operationally efficient solution that meets these requirements would be to use option B, which is to use AWS Backup to create backup schedules and retention policies for the table. AWS Backup is a fully managed backup service that makes it easy to centralize and automate the backup of data across AWS resources. It allows you to create backup policies and schedules to automatically back up your DynamoDB tables on a regular basis. You can also specify retention policies to ensure that your backups are retained for the required period of time. This solution is fully automated and requires minimal maintenance, making it the most operationally efficient option.
Comment: Option A, using DynamoDB point-in-time recovery, is also a viable option but it requires continuous backup, which may be more resource-intensive and may incur higher costs compared to using AWS Backup. Option C, creating an on-demand backup of the table and storing it in an S3 bucket, is also a viable option but it requires manual intervention and does not provide the automation and scheduling capabilities of AWS Backup. Option D, using Amazon EventBridge (CloudWatch Events) and a Lambda function to back up the table and store it in an S3 bucket, is also a viable option but it requires more complex setup and maintenance compared to using AWS Backup.
Comment: Ans B - there are no special parameters specified for the backup (eg. PITR snapshots) so it doesn't need to be elaborate
Comment: Agreed with option B is the right one. AWS backup retention goes from 1 day to 100 years (or even indefinitely, if you do not enter a retention period), so will meet the requirements.
Comment: Why is the answer not C?
Comment: As I see, we are looking for the most operationally efficient solution. So it's B, but the most cost effective its - C (but it isn't a question).
Comment: https://youtu.be/g4WPLFXLwDE?si=nTWqqDcBe_Y6dtl3
Comment: Operational efficiency is always a managed service from AWS. AWS Backup is the right one in this case so B is right answer
Comment: Answer is simply B as it if MOST operationally efficient. Other options are "distractors" to confuse everyone.
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorksAWS.html
Comment: Well a 7 years TTL on the dynamoDB records could be the simpliest to answer the question, so B for the "retention policies". And since the B also propose AWS backup with a retention time at 7 years, why not.
Comment: The key advantages of using AWS Backup are: Fully managed backup service requiring minimal operational overhead Built-in scheduling, retention policies, and backup monitoring Supports point-in-time restore for DynamoDB Automated and scalable solution
Comment: B - is the answer because its easy to setup via AWS Backup & It indicates the keyword "MOST Operational Efficient". Other answers are indicating Cost efficient
Comment: AWS Backup is a fully managed backup service that simplifies the process of creating and managing backups across various AWS services, including DynamoDB. It allows you to define backup schedules and retention policies to automatically take backups and retain them for the desired duration. By using AWS Backup, you can offload the operational overhead of managing backups to the service itself, ensuring that your data is protected and retained according to the specified retention period. This solution is more efficient compared to the other options because it provides a centralized and automated backup management approach specifically designed for AWS services. It eliminates the need to manually configure and maintain backup processes, making it easier to ensure data retention compliance without significant operational effort.
Comment: A PITR is used to recover your table to any point in time in a rolling 35 day window, which is used to help customers mitigate accidental deletes or writes to their tables from bad code, malicious access, or user error. (==> A is the answer)
Comment: using AWS Backup cheaper than DynamoDB point-in-time recovery
Comment: With less overhead is AWS Backups: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorksAWS.html
Comment: To retain data for 7 years in an Amazon DynamoDB table, you can use AWS Backup to create backup schedules and retention policies for the table. You can also use DynamoDB point-in-time recovery to back up the table continuously.
Comment: On-demand mode is a good option if any of the following are true: - You create new tables with unknown workloads. - You have unpredictable application traffic. - You prefer the ease of paying for only what you use.
Comment: **A** - On demand is the answer - https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.OnDemand B - not related with the unpredictable traffic C - provisioned capacity is recommended for known patterns. Not the case here. D - same as C
Comment: Thanks. Your reference link perfectly supports the option "A". 100% correct
Comment: Ans A - handles unpredictable workloads/traffic; pay on demand C - provisioned capacity for known data I/O - not the case here
Comment: Unpredictable = On-demand
Comment: cost is concern so CD are not right as provisioning is costly B is irrelevant A on-demand is correct as it will scale according to the usage pattern which is from low to very abrupt high
Comment: Choosing the On-Demand Capacity model (Option A) may cause performance issues during peak periods because it relies on DynamoDB to automatically adjust throughput based on actual usage, which may not be able to cope with sudden traffic increases in time. Choosing a DynamoDB table with a global secondary index (option B) is independent of the capacity model and does not directly solve the problem of peak traffic. Choosing to build DynamoDB tables in provisioned capacity mode and configure them as global tables (option D) may increase costs in some cases without necessarily providing the flexibility to accommodate unpredictable peak traffic.
Comment: sorry I want to chang my answer to A . Because the point is the " cost "
Comment: DynamoDB autoscaling takes 2 minutes to increase capacity. We need to handle it immediately. "Application Auto Scaling automatically scales the provisioned capacity only when the consumed capacity is higher than target utilization for two consecutive minutes". https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html
Comment: This is important, thank you for the link. A definitely
Comment: The costly part of (C) is you need to pay for what you order not what you have used for (A) On-Demand: A reserved capacity purchase is an agreement to pay for a minimum amount of provisioned throughput capacity, for the duration of the term of the agreement, in exchange for discounted pricing. If you use less than your reserved capacity, you will still be charged each month for that minimum amount of provisioned throughput capacity.
Comment: https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html With on-demand capacity mode, DynamoDB charges you for the data reads and writes your application performs on your tables. You do not need to specify how much read and write throughput you expect your application to perform because DynamoDB instantly accommodates your workloads as they ramp up or down. With provisioned capacity mode, you specify the number of reads and writes per second that you expect your application to require, and you are billed based on that. Furthermore if you can forecast your capacity requirements you can also reserve a portion of DynamoDB provisioned capacity and optimize your costs even further.
Comment: With on-demand capacity mode, DynamoDB instantly accommodates your workloads as they ramp up or down.
Comment: on-demand capacity : unpredictable application traffic provisioned capacity : predictable application traffic, run applications whose traffic is consistent, and ramps up or down gradually. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html
Comment: By choosing provisioned capacity, you can allocate a specific amount of read and write capacity units based on your expected usage during peak times. This helps in cost optimization as you only pay for the provisioned capacity, which can be adjusted according to your anticipated traffic. Enabling auto scaling allows DynamoDB to automatically adjust the provisioned capacity up or down based on the actual usage. This is beneficial in handling quick traffic spikes without manual intervention and ensuring that the required capacity is available to handle increased load efficiently. Auto scaling helps to optimize costs by dynamically adjusting the capacity to match the demand, avoiding overprovisioning during periods of low usage. A. Creating a DynamoDB table in on-demand capacity mode, may not be the most cost-effective solution in this scenario. On-demand capacity mode charges you based on the actual usage of read and write requests, which can be beneficial for sporadic or unpredictable workloads. However, it may not be the optimal choice if the table is not used on most mornings.
Comment: Correct answer is A - You create new tables with unknown workloads. - You have unpredictable application traffic. - You prefer the ease of paying for only what you use.
Comment: "On-demand" is a good option for applications that have unpredictable or sudden spikes, since it automatically provisions read/write capacity. "Provisioned capacity" is suitable for applications with predictable usage.
Comment: Answer is A. Provisioned capacity is best if you have relatively predictable application traffic, run applications whose traffic is consistent, and ramps up or down gradually. On-demand capacity mode is best when you have unknown workloads, unpredictable application traffic and also if you only want to pay exactly for what you use. The on-demand pricing model is ideal for bursty, new, or unpredictable workloads whose traffic can spike in seconds or minutes, and when under-provisioned capacity would impact the user experience. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html
Comment: For unpredictable cases there's no way you can provision something, as it cannot be predicted, so the answer is A
Comment: On-demand capacity mode allows a DynamoDB table to automatically scale up or down based on the traffic to the table. This means that capacity will be allocated as needed and billing will be based on actual usage, providing flexibility in capacity while minimizing costs. This is an ideal choice for a table that is not used on most mornings and has unpredictable traffic spikes in the evenings.
Comment: Share the existing KMS key with the MSP external account because it has already been used to encrypt the AMI snapshot. https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
Comment: ***CORRECT*** B. Modify the launchPermission property of the AMI. The most secure way for the solutions architect to share the AMI with the MSP Partner's AWS account would be to modify the launchPermission property of the AMI and share it with the MSP Partner's AWS account only. The key policy should also be modified to allow the MSP Partner's AWS account to use the key. This ensures that the AMI is only shared with the MSP Partner and is encrypted with a key that they are authorized to use.
Comment: Option A, making the AMI and snapshots publicly available, is not a secure option as it would allow anyone with access to the AMI to use it. Option C, modifying the key policy to trust a new KMS key owned by the MSP Partner, is also not a secure option as it would involve sharing the key with the MSP Partner, which could potentially compromise the security of the data encrypted with the key. Option D, exporting the AMI to an S3 bucket in the MSP Partner's AWS account and encrypting the S3 bucket with a new KMS key owned by the MSP Partner, is also not the most secure option as it involves sharing the AMI and a new key with the MSP Partner, which could potentially compromise the security of the data.
Comment: Ans B - keep the control simple by only allowing MSP Partner access to the key
Comment: AD are unsecure. I was confused between B and C but read the article (link below). You have to allow the other account to use your key somehow otherwise they won't be able to use your AMI. C just allows a trust relationship with MSP's KMS, it won't give them access to your key. https://aws.amazon.com/blogs/security/how-to-share-encrypted-amis-across-accounts-to-launch-encrypted-ec2-instances/
Comment: when you export AMI to s3 bucket it remains encrypted, so partner couldn't launch ec2 instance
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html
Comment: Share the AMI and Key with the MSP Partner's AWS account only
Comment: B - is the Answer https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
Comment: By modifying the launchPermission property of the AMI and sharing it with the MSP Partner's account only, the solutions architect restricts access to the AMI and ensures that it is not publicly available. Additionally, modifying the key policy to allow the MSP Partner's account to use KMS customer managed key used for encrypting the EBS snapshots ensures that the MSP Partner has the necessary permissions to access and use the key for decryption.
Comment: CORRECTION to my last comment Option B is correct not A. Explanation why.. Making the AMI and snapshots publicly available, is not a secure option as it would allow anyone with access to the AMI to use it. Best practice would be to share the AMI with the MSP Partner's AWS account then Modify launchPermission property of the AMI. This ensures that the AMI is shared only with the MSP Partner and is encrypted with a key that they are authorised to use.
Comment: Option A, making the AMI and snapshots publicly available, is not a secure option as it would allow anyone with access to the AMI to use it. Best practice would be to share the AMI with the MSP Partner's AWS account then Modify launchPermission property of the AMI. This ensures that the AMI is shared only with the MSP Partner and is encrypted with a key that they are authorised to use.
Comment: Option D
Comment: Option B
Comment: Must use and share the existing KMS key to decrypt the same key
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/acm-certificate-expiration/
Comment: If EBS snapshots are encrypted, then we need to share the same KMS key to partners to be able to access it. Read the note section in the link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html
Comment: MOST secure way should be C
Comment: B AWS Config has a managed rule named acm-certificate-expiration-check to check for expiring certificates (configurable number of days)
Comment: It does not have a built-in rule for checking the expiration of ACM certificates directly.
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/acm-certificate-expiration/
Comment: Answer B and answer D are possible according to this article. So, need to read B & D carefully to determine the most suitable answer. Reference: https://aws.amazon.com/premiumsupport/knowledge-center/acm-certificate-expiration/
Comment: But from the link shared. It doesnt state that you should invoke lambda function as stated in option D. Option B is explicitly stated in the article as also worded in option B. So i think B should be the answer. My thought though. i stand to be corrected.
Comment: Its B, simply because in option D - event bridge cannot "detect" anything.
Comment: My understanding is that the ACM sends a Cert Expiration event to EventBridge. Thus EB. does not need to detect anything.
Comment: "ACM sends a Cert Expiration event to EventBridge" yes, but 45 (not 30) days before expiration.
Comment: This can be configured to whatever you need in the Days to expiry box
Comment: AWS Certificate Manager (ACM) now publishes certificate metrics and events through Amazon CloudWatch and Amazon EventBridge. https://aws.amazon.com/about-aws/whats-new/2021/03/aws-certificate-manager-provides-certificate-expiry-monitoring-through-amazon-cloudwatch/
Comment: B costs more than D To get a notification that your certificate is about to expire, use one of the following methods: Use the ACM API in Amazon EventBridge to configure the ACM Certificate Approaching Expiration event. Create a custom EventBridge rule to receive email notifications when certificates are nearing the expiration date. Use AWS Config to check for certificates that are nearing the expiration date. If you use AWS Config for this resolution, then be aware of the following: Before you set up the AWS Config rule, create the Amazon Simple Notification Service (Amazon SNS) topic and EventBridge rule. This makes sure that all non-compliant certificates invoke a notification before the expiration date. Activating AWS Config incurs an additional cost based on usage. For more information, see AWS Config pricing. https://repost.aws/knowledge-center/acm-certificate-expiration
Comment: Nobody asked for cost optimization.
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/acm-certificate-expiration/
Comment: D- because it notified 30 days BEFORE the expiration of each certificate
Comment: The first of the two options I describe is to use the ACM built-in Certificate Expiration event, which is raised through Amazon EventBridge, to invoke a Lambda function. In this option, the function is configured to publish the result as a finding in Security Hub, and also as an SNS topic used for email subscriptions. As a result, an administrator can be notified of a specific expiring certificate, or an IT service management (ITSM) system can automatically open a case or incident through email or SNS.
Comment: Answer is D. Operational Overhead: Using AWS Config for this purpose might add unnecessary operational overhead, as it involves additional configuration and management steps compared to a more direct EventBridge and Lambda setup.
Comment: D
Comment: I think B is correct
Comment: Ans D - I must admit it wasn't clear until I read... "zhaoxiaobing101" (1 week, 5 days ago): "AWS Config is primarily designed for compliance monitoring rather than straightforward event detection like certificate expiration. It requires setting up compliance rules and monitoring them, which adds complexity. By focusing directly on the task at hand, D minimizes operational overhead and simplifies the architecture, making it the better choice for the specific requirement of monitoring and alerting on certificate expiration."
Comment: AWS Config is primarily designed for compliance monitoring rather than straightforward event detection like certificate expiration. It requires setting up compliance rules and monitoring them, which adds complexity. By focusing directly on the task at hand, D minimizes operational overhead and simplifies the architecture, making it the better choice for the specific requirement of monitoring and alerting on certificate expiration.
Comment: AWS config dont have capacity to check expiration
Comment: D https://aws.amazon.com/blogs/security/how-to-monitor-expirations-of-imported-certificates-in-aws-certificate-manager-acm/
Comment: AWS config rule to check the certificate expiry and with Event bridge to invoke an event to notify if certificate going to expiry
Comment: You would need event bridge to invoke lambda. That is missing in the option D
Comment: D Not B because AWS Config is more suitable for monitoring configuration compliance rather than tracking the expiry of certificates. Setting up an AWS Config rule specifically for certificate expiration would be complex and less efficient compared to using EventBridge.
Comment: The answer is D because: If you want to set up notifications for more than 45 days before an event's expiration, then use the alternative following methods. Create a custom EventBridge rule Use a custom event pattern with an EventBridge rule to match the AWS Config managed rule acm-certificate-expiration-check. Then, route the response to an Amazon Simple Notification Service topic. So if you want to be notified 30 days before expiration, you wont use aws config. Link: https://repost.aws/knowledge-center/acm-certificate-expiration
Comment: The correct answer is B bc: (LeGloupier has a popular post on this) https://repost.aws/knowledge-center/acm-certificate-expiration#:~:text=To%20get%20a%20notification%20that%20your%20certificate%20is%20about%20to%20expire%2C%20use%20one%20of%20the%20following%20methods%3A D IS INCORRECT bc: -Lambda is not necessary; AWS services (such as Amazon EC2, Amazon S3 & Amazon CloudWatch) can publish messages to your SNS topics to trigger event-driven computing and workflows. Using Lambda here goes against building the Well-Architected Framework pillar of Performance Efficiency. The more efficient solution is to use the managed service of AWS Config. -For those that argue against (B) bc of cost: The Cost Optimization pillar is upheld by (B) vs (D). Understanding how efficient your current architecture is in relation to your goals can remove unneeded expense. The goal is for the security team to be notified B4 expiration. If the certificate expires, there will be a far greater expense to pay.
Comment: AWS Config has a managed rule named acm-certificate-expiration-check to check for expiring certificates (configurable number of days)
Comment: ***CORRECT*** C. Use Amazon CloudFront with a custom origin pointing to the on-premises servers. Amazon CloudFront is a content delivery network (CDN) that speeds up the delivery of static and dynamic web content, such as HTML, CSS, JavaScript, images, and videos. By using CloudFront, the company can distribute the content of their website from edge locations that are closer to the users in Europe, reducing the loading times for these users. To use CloudFront, the company can set up a custom origin pointing to their on-premises servers in the United States. CloudFront will then cache the content of the website at edge locations around the world and serve the content to users from the location that is closest to them. This will allow the company to optimize the loading times for their European users without having to move the backend of the website to a different region.
Comment: excelente explicação
Comment: good explanation..thanks
Comment: ***WRONG*** Option A (launch an Amazon EC2 instance in us-east-1 and migrate the site to it) would not address the issue of optimizing loading times for European users. Option B (move the website to Amazon S3 and use Cross-Region Replication between Regions) would not be an immediate solution as it would require time to set up and migrate the website. Option D (use an Amazon Route 53 geoproximity routing policy pointing to on-premises servers) would not be suitable because it would not improve the loading times for users in Europe.
Comment: S3 doesn't support dynamic website hosting. Therefore, can be ruled out.
Comment: C for sure
Comment: Ans C... I was going for D, then I saw (CookieMr, 1yr 2mth ago) "Route 53 geoproximity routing policy in does allow you to direct traffic to the on-premises servers based on the geographic location of the users - BUT does not optimised site loading times for European users as it still requires them to access the website from the on-prem servers in the US."
Comment: C is the appropriate answer
Comment: Immediate solution is C A: Requires site migration so won't be immediate B: Dynamic site cannot work from S3 D: Geoproximity routing policy finds a server close to the user so this makes no sense C: Not ideal but best option given the "immediate" requirement as CloudFront is a CDN so it will cache whatever is possible as close to the user giving best performance in this case (i.e. when compared to other options)
Comment: C. Use Amazon CloudFront with a custom origin pointing to the on-premises servers.
Comment: The key reasons are: CloudFront can cache static content close to European users using edge locations, improving site performance. The custom origin feature allows seamlessly integrating the CloudFront CDN with existing on-premises servers. No changes are needed to the site backend or servers. CloudFront just acts as a globally distributed cache. This can be set up very quickly, meeting the launch deadline. Other options like migrating to EC2 or S3 would require more time and changes. CloudFront is an easier lift. Route 53 geoproximity routing alone would not improve performance much without a CDN.
Comment: C. This solution leverages the global network of CloudFront edge locations to cache and serve the website's static content from the edge locations closest to the European users. A. Hosting the website in a single region would still result in increased latency for European users accessing the site. B. Moving the website to S3 and implementing Cross-Region Replication would distribute the website's content across multiple regions, including Europe. S3 is primarily used for static content hosting, and it does not provide server-side processing capabilities necessary for dynamic website functionality. D. Using a geoproximity routing policy in Route 53 would allow you to direct traffic to the on-premises servers based on the geographic location of the users. However, this option does not optimize site loading times for European users as it still requires them to access the website from the on-premises servers in the United States. It does not leverage the benefits of content caching and edge locations for improved performance.
Comment: C is best solution.
Comment: Within few days you can not do more than using CloudFront
Comment: Option C
Comment: C is correct answer
Comment: CloudFront = CDN Service
Comment: C. S3 Cross region Replication minimize latency but also copies objects across Amazon S3 buckets in different AWS Regions(data has to remain in origin thou) so B wrong. Route 53 geo, does not help reducing the latency.
Comment: C is correct
Comment: Same question with detailed explanation https://www.examtopics.com/discussions/amazon/view/27898-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Option C, use CloudFront.
Comment: Spot blocks are not longer available, and you can't use spot instances on Prod machines 24x7, so option B should be valid.
Comment: Option B, would indeed be the most cost-effective solution. Reserved Instances provide cost savings for instances that run consistently, such as the production environment in this case, while On-Demand Instances offer flexibility and are suitable for instances with variable usage patterns like the development and test environments. This combination ensures cost optimization based on the specific requirements and usage patterns described in the question.
Comment: In addition to this, we can set up an automated process to start and stop the EC2 instances in the test and dev environment
Comment: Ans B - A: Spot instances are not ideal for production due to possibility of not running C,D: Spot blocks discontinued. That leaves option B
Comment: B is the right answer
Comment: Either a trick question, or an old question. The answer is B; spot blocks were discontinued by Amazon, July 2021.
Comment: Option A,C: Production workload must not run on spot instances. Option D: No savings(compared to reserved Instances) for prod as its on-demand, Spot Blocks are no longer available. So correct answer is B
Comment: Isn't this simple or am I thinking wrong? "The production EC2 instances run 24 hours a day" AC are not going to give the 24 hour usage as spot is for intermittent pattern. D is just normal cost without any discounts for production B use "reserved" instances so there is an option for discount in billing. On-demand for dev/test is ok as their usage patter doesn't really fall in reserved or spot usage discounts
Comment: B = Reserved for Prod and On Demand for Dev
Comment: B meets the requirements, and most cost-effective.
Comment: Spot instances are not suitable for production due to the possibility of not running.
Comment: Answeer B: Sopt block are not longer available and you can't use spot instace on production
Comment: Well, AWS has DISCONTINUED the Spot-Block option. so that rules out the two options that use spot-block. Wait, this question must be from SAA-C02 or even 01. STALE QUESTION. I don't think this will feature in SAA-C03. Anyhow, the most cost-effective solution would be Option "b"
Comment: Choosing B as spot blocks (Spot instances with a finite duration) are no longer offered since July 2021
Comment: https://aws.amazon.com/ec2/spot/?cards.sort-by=item.additionalFields.startDateTime&cards.sort-order=asc&trk=8e336330-37e5-41e0-8438-bc1c75320d09≻_channel=ps&ef_id=CjwKCAjw67ajBhAVEiwA2g_jECgIX_lcbqawbH-wVx2Y_EozBm8xv3g3Ci1eps0V49XcZRyfuy9xPhoCOkcQAvD_BwE:G:s&s_kwcid=AL!4422!3!517520538467!p!!g!!aws%20ec2%20spot!12831094520!122300635918
Comment: The most cost-effective solution for the company's requirements would be to use Spot Instances for the development and test EC2 instances and Reserved Instances for the production EC2 instances. Spot Instances are a cost-effective choice for non-critical, flexible workloads that can be interrupted. Since the development and test EC2 instances are only needed for at least 8 hours per day and can be stopped when not in use, they would be a good fit for Spot Instances.
Comment: Reserved instances are a better choice when compared to spot instances because spot instance cannot be used for 24/7 running instances as stated in this scenario.
Comment: Reserved Instances are a good fit for production EC2 instances that need to run 24 hours a day, as they offer a significant discount compared to On-Demand Instances in exchange for a one-time payment and a commitment to use the instances for a certain period of time. Option A is the correct answer because it meets the company's requirements for cost-effectively running the development and test EC2 instances and the production EC2 instances.
Comment: Option B is not the most cost-effective solution because it suggests using On-Demand Instances for the development and test EC2 instances, which would be more expensive than using Spot Instances. On-Demand Instances are a good choice for workloads that require a guaranteed capacity and can't be interrupted, but they are more expensive than Spot Instances. Option C is not the correct solution because Spot blocks are a variant of Spot Instances that offer a guaranteed capacity and duration, but they are not available for all instance types and are not necessarily the most cost-effective option in all cases. In this case, it would be more cost-effective to use Spot Instances for the development and test EC2 instances, as they can be interrupted when not in use.
Comment: Can't use Spot instances for Production environment that needs to run 24/7. That should tell you that Production instances can't have a downtime. Spot instances are used when an application or service can allow disruption and 24/7 production environment won't allow that.
Comment: Option D is not the correct solution because it suggests using On-Demand Instances for the production EC2 instances, which would be more expensive than using Reserved Instances. On-Demand Instances are a good choice for workloads that require a guaranteed capacity and can't be interrupted, but they are more expensive than Reserved Instances in the long run. Using Reserved Instances for the production EC2 instances would offer a significant discount compared to On-Demand Instances in exchange for a one-time payment and a commitment to use the instances for a certain period of time.
Comment: The production EC2 instances run 24 hours a day.
Comment: A says to use Spot instances for production, which is nonsense as production must run "24 hours a day." Even DEV and TEST can't use Spot because you can't guarantee that they are available for "at least 8 hours each day". That rules out everything but B.
Comment: Option B
Comment: Option B
Comment: Reserved instances for 24/7 production instances seems reasonable. By exclusion I will choose the on-demand for dev and test (despite thinking that Spot Flees may be even a better solution from a cost-wise perspective)
Comment: Secrets Manager enables you to replace hardcoded credentials in your code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. This helps ensure the secret can't be compromised by someone examining your code, because the secret no longer exists in the code. Also, you can configure Secrets Manager to automatically rotate the secret for you according to a specified schedule. This enables you to replace long-term secrets with short-term ones, significantly reducing the risk of compromise. https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
Comment: B. SSM OpsCenter is primarily used for managing and resolving operational issues. It is not designed to securely store and manage credentials like AWS Secrets Manager. C. Storing credentials in an S3 bucket may provide some level of security, but it lacks the additional features and security controls offered by AWS Secrets Manager. D. While using KMS for encryption is a good practice, managing credentials directly on the web server file system can introduce complexities and potential security risks. It can be challenging to securely manage and rotate credentials across multiple web servers, especially when considering scalability and automation. In summary, option A is the recommended solution as it leverages AWS Secrets Manager, which is purpose-built for securely storing and managing secrets, and provides the necessary IAM permissions to allow the web servers to access the credentials securely.
Comment: Ans A - Secrets Manager, auto rotates...
Comment: A is the right answer, you should never store any of your credentials in files, even if they are encrypted. Also, secrets manager fulfills the credentials rotation condition.
Comment: While I agree that A is the most feasible answer, I don't see how it satisfies the "a secure method for the web servers to connect to the database" requirement. ASM is about securely storing and rotating secrets, but has nothing to do with "secure connection" between the web servers and RDS. That would require something like IAM DB authentication, which is not even mentioned.
Comment: Yeah, It's a stupid question.
Comment: rotation = SM
Comment: AWS Secrets Manager is best for storing credentials and supports auto rotation so A is the best choice
Comment: A = Rotation of user credentials can be automated using Secrets Manager.
Comment: option A is the recommended solution as it leverages AWS Secrets Manager, which is purpose-built for securely storing and managing secrets, and provides the necessary IAM permissions to allow the web servers to access the credentials securely.
Comment: AWS Secrets Manager to the rescue....up up and awaaaay
Comment: The correct answer is A. Here is the explanation: AWS Secrets Manager is a service that helps you store, manage, and rotate secrets. Secrets Manager is a good choice for storing database user credentials because it is secure and scalable. IAM permissions can be used to grant web servers access to AWS Secrets Manager. This will allow the web servers to retrieve the database user credentials from Secrets Manager and use them to connect to the database. Rotation of user credentials can be automated using Secrets Manager. This will ensure that the database user credentials are rotated on a regular basis, meeting the security requirement.
Comment: Option A is ans.
Comment: A is correct
Comment: literally screams for AWS secrets manager to rotate the credentails
Comment: ***CORRECT*** Option A. Store the database user credentials in AWS Secrets Manager. Grant the necessary IAM permissions to allow the web servers to access AWS Secrets Manager. Option A is correct because it meets the requirements specified in the question: a secure method for the web servers to connect to the database while meeting a security requirement to rotate user credentials frequently. AWS Secrets Manager is designed specifically to store and manage secrets like database credentials, and it provides an automated way to rotate secrets every time they are used, ensuring that the secrets are always fresh and secure. This makes it a good choice for storing and managing the database user credentials in a secure way.
Comment: ***WRONG*** Option B, storing the database user credentials in AWS Systems Manager OpsCenter, is not a good fit for this use case because OpsCenter is a tool for managing and monitoring systems, and it is not designed for storing and managing secrets. Option C, storing the database user credentials in a secure Amazon S3 bucket, is not a secure option because S3 buckets are not designed to store secrets. While it is possible to store secrets in S3, it is not recommended because S3 is not a secure secrets management service and does not provide the same level of security and automation as AWS Secrets Manager.
Comment: Option D, storing the database user credentials in files encrypted with AWS Key Management Service (AWS KMS) on the web server file system, is not a secure option because it relies on the security of the web server file system, which may not be as secure as a dedicated secrets management service like AWS Secrets Manager. Additionally, this option does not meet the requirement to rotate user credentials frequently because it does not provide an automated way to rotate the credentials.
Comment: Option A
Comment: Rotate credentials = Secrets Manager
Comment: https://aws.amazon.com/rds/proxy/ RDS Proxy minimizes application disruption from outages affecting the availability of your database by automatically connecting to a new database instance while preserving application connections. When failovers occur, RDS Proxy routes requests directly to the new database instance. This reduces failover times for Aurora and RDS databases by up to 66%.
Comment: The original question was about handling a situation where the database is unavailable due to an upgrade, not a failover situation. During a database upgrade, the database instance is not available, and RDS Proxy would not be able to connect to a new database instance because there isn't one. In this specific scenario, using Amazon SQS as described in option D provides a buffer for the incoming data during the period when the database is unavailable. This ensures that no data is lost, and it can be written to the database once the upgrade is complete.
Comment: so many upvotes for an incorrect answer. the question doesnt mention having more than one DB so how does RDS proxy help here?
Comment: This is MySQL Database. RDS proxy = no no
Comment: It literally says RDS Proxy is available for Aurora MySQL on the link in the comment you're replying to.
Comment: But still RDS proxy won't help because during upgrades there is no database that it could proxy to.
Comment: Aurora supports RDS proxy! https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: The answer is D. RDS Proxy doesn't support Aurora DBs. See limitations at: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: You can use RDS Proxy with Aurora Serverless v2 clusters but not with Aurora Serverless v1 clusters. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: It does, according to that link
Comment: This not RDS supports Aurora mysl database. All the limitations listed in the link you posted above are not related to the question, hence the answer is B
Comment: I meant the answer answer is A
Comment: Actually RDS Proxy supports Aurora DBs running on PostgreSQL and MySQL. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.html With RDS proxy, you only expose a single endpoint for request to hit and any failure of the primary DB in a Multi-AZ configuration is will be managed automatically by RDS Proxy to point to the new primary DB. Hence RDS proxy is the most efficient way of solving the issue as additional code change is required. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.howitworks.html
Comment: The question doesn't say the RDS is deployed in a Mutli-AZ mode. which means RDS is not accessible during upgrade anyway. RDS proxy couldn't resolve the DB HA issue. The question is looking for a solution to store the data during DB upgrade. I don't know RDS proxy very well, but the RDS proxy introduction doesn't mention it has the capability of storing data. So, answer A couldn't store the data created during the DB upgrade. I'm assuming this is a bad question design. The expected answer is A, but the question designer missed some important information.
Comment: https://aws.amazon.com/rds/proxy/, if you go down the page, you will see that RDS is deployed in Multi-AZ (mazon RDS Proxy is highly available and deployed over multiple Availability Zones (AZs) to protect you from infrastructure failure. Each AZ runs on its own physically distinct, independent infrastructure and is engineered to be highly reliable. In the unlikely event of an infrastructure failure, the RDS Proxy endpoint remains online and consistent allowing your application to continue to run database operations.) from the link.
Comment: A for sure
Comment: It's not a failover situation, it's just temporarily unavailable.
Comment: Ans D - as excellently explained by SaurabhTiwari1 (9 mth ago) "The original question was about handling a situation where the database is unavailable due to an upgrade, not a failover situation. During a database upgrade, the database instance is not available, and RDS Proxy would not be able to connect to a new database instance because there isn't one." In this specific scenario, using Amazon SQS as described in option D provides a buffer for the incoming data during the period when the database is unavailable. This ensures that no data is lost, and it can be written to the database once the upgrade is complete
Comment: A is incorrect
Comment: the answer is D: This solution ensures that customer data is not lost during database upgrades. The data is stored in the FIFO queue until the database is available again. The new Lambda function can then process the data from the queue and store it in the database. This design provides a buffer for the customer data and decouples the data ingestion from the data processing, increasing the resilience of the system during database upgrades.
Comment: By using Amazon RDS Proxy, you can allow your applications to pool and share database connections to improve their ability to scale. RDS Proxy makes applications more resilient to database failures by automatically connecting to a standby DB instance while preserving application connections. Using RDS Proxy, you can handle unpredictable surges in database traffic. Otherwise, these surges might cause issues due to oversubscribing connections or new connections being created at a fast rate.
Comment: D is the correct answer because it offers storage for the data while the database is updating, using SQS is better than using RDS proxy, because SQS is an independent service and it decouples the system, while RDS proxy might also face some trouble connecting to the database while it's updating.
Comment: My reasoning for selecting D and not A is because while RDS proxy can decouple the lambda->proxy and proxy-db connections, it cannot hold that beyond the lifetime of the lambda. If the DB upgrade lasts more than say 15 mins, the lambda will timeout and the data will be lost forever. The only way to be sure is to use an SQS queue with a retention time that is reasonably longer than the upgrade time, so if the lambda times out, the data will remain in the queue until it is successfully inserted into the DB later and then removed from the queue.
Comment: RDS proxy can improve application availability in such a situation by waiting for the new database instance to be functional and maintaining any requests received from the application during this time. The end result is that the application is more resilient to issues with the underlying database. This will enable solution to hold data till the time DB comes back to normal.
Comment: d is the answer
Comment: Originally I felt option A is correct but looks like D is correct since even though rds proxy can support aurora db and minor db upgrades, the question mentions the db upgrades which could be major or minor in which case rds proxy may not be right.
Comment: Amazon SQS FIFO Queue: Amazon SQS FIFO (First-In-First-Out) queues provide exactly-once processing, ensuring that messages are processed in the order they are received and are not duplicated. This ensures the reliability of message delivery, crucial for preserving customer data. Lambda Function to Process Queue: Create a new Lambda function that regularly polls the SQS FIFO queue for messages containing customer data. Lambda can be configured to trigger based on a schedule or on demand. This function will retrieve messages from the queue and process them, storing the customer data in the database.
Comment: RDS proxy is correct Many applications, including those built on modern serverless architectures, can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability. With RDS Proxy, failover times for Aurora and RDS databases are reduced by up to 66% and database credentials, authentication, and access can be managed through integration with AWS Secrets Manager and AWS Identity and Access Management (IAM).
Comment: What EVERYONE is failing to remember is that when a database is doing an upgrade that ALL instances of the database are offline, whether multi-AZ or read replicas or whatever...these are not 'open' connections, they are failed connections. Where, exactly, would RDS Proxy be proxying to?
Comment: This option introduces a decoupling mechanism using SQS, allowing the Lambda functions to push customer data to a queue during database upgrades. Another Lambda function can then process the queue and store the customer data in the database. This helps to ensure that customer data is not lost during database upgrades, providing a reliable and asynchronous approach to handle such scenarios.
Comment: Option to have RDS Proxy is available, then why to go other routes ?
Comment: From Amazon Q: RDS Proxy can be used with Amazon Aurora. Here are some key points about using RDS Proxy with Aurora: RDS Proxy supports connecting to Aurora MySQL and Aurora PostgreSQL databases. This allows applications to connect to Aurora clusters via the proxy. Using a proxy provides better scalability by allowing connections to be distributed among Aurora replica instances. It also improves availability since the proxy can direct connections to other Aurora replicas if the primary becomes unavailable. The Aurora database and RDS Proxy must be in the same VPC to allow connections. Your applications can be deployed in the same VPC or a different one, as long as they have network access to the proxy. Certain regions and Aurora engine versions support RDS Proxy based on the database engine. You can check the AWS documentation for the latest supported versions in each region.
Comment: The database and proxy need appropriate security group rules and IAM permissions configured to allow connections. The RDS Proxy also requires a secret with database credentials stored in Secrets Manager. You would connect applications to the proxy endpoint rather than directly connecting to the Aurora endpoint. This allows the proxy to handle and load balance connections to the Aurora replicas. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy-setup.html
Comment: this question is too vague imho if the question is looking for a way to incur charges to the European company instead of the US company, then requester pay makes sense. if they are looking to reduce overall data transfer cost, then B makes sense because the data does not leave the AWS network, thus data transfer cost should be lower technically? A. makes sense because the US company saves money, but the European company is paying for the charges so there is no overall saving in cost when you look at the big picture I will go for B because they are not explicitly stating that they want the other company to pay for the charges
Comment: I disagree with your opinion, because S3 Cross-Region is only transfer new data to new region, the old data can't. So A is correct.
Comment: I disagree. The question says, "the company wants to ensure that ITS data transfer costs remain as low as possible" -- 'it' being the US company. The question would have stayed "ensure that data transfer costs" (without the word 'its') if they meant the overall data transfer cost.
Comment: I don't agree with your explanation, you are overthinking it in wrong direction.
Comment: What if company decides to share data with 10 new companies ? Why would a company pay for data transfer when there is a requestor pay feature available.
Comment: I concur with your explanation 100%
Comment: Agree, B) Cross Region Replication: $0.02/GB A) over the internet it is $0.09/GB Answer is B
Comment: is S3 Cross-Region Replication works between 2 separate aws accounts? shouldn't the answer is C?
Comment: "C" can't be the answer as it means the S3 data access survey company will incur the cost when data is accessed by European company.
Comment: "Typically, you configure buckets to be Requester Pays buckets when you want to share data but not incur charges associated with others accessing the data. For example, you might use Requester Pays buckets when making available large datasets, such as zip code directories, reference data, geospatial information, or web crawling data." https://docs.aws.amazon.com/AmazonS3/latest/userguide/RequesterPaysBuckets.html
Comment: Per my understanding, the company is already paying to maintain the data(data keeps growing) in the S3 bucket. The company wants to ensure that its data transfer costs remain as low as possible (implies that it is best if the transfer cost is $0). As per option A, the requestor would bear the cost of the request and the data downloaded from the bucket, causing the data owner to incur a $0 transfer cost, which is optimal for the data owner. The question does not say that the data owner must also consider the cost incurred by the requestor and then find an optimal cost solution.
Comment: No idea but I guess B. request payer sounds like stpd
Comment: it's A because the company will not pay extra cost
Comment: Ans B... because we want an overall cost-effective solution; A simply offloads the cost to someone else...
Comment: replication cost money . in other for the sender company to cut cost the requester must pay the transfer cost .Leveraging the requester pay options is convenient on the part of the company that is sharing .
Comment: because in question we are said to reduce our charges not to completely put them on the other organization
Comment: Correct A. Configure the Requester Pays feature on the company's S3 bucket. This feature ensures that the party requesting the data pays for the data transfer costs instead of the bucket owner. Incorrect B. Configure S3 Cross-Region Replication from the company's S3 bucket to one of the marketing firm's S3 buckets. Cross-Region Replication incurs additional storage and transfer costs as data is replicated across regions. This would increase costs rather than reduce them.
Comment: Option B makes more sense because the data transferred remains within the AWS private network, in my opinion, option A is incorrect because it doesn't reduce the overall transfer charges, it just shifts them from the American company to the European company.
Comment: Definitely B
Comment: both are part of same company. Option A still incur changes for the company. Option B will help to save some cost sharing the data in both the regions.
Comment: Answer: A
Comment: 100% answer is A. Question doesnt state anything about the other company saving costs, only the US company.
Comment: (A) IS INCORRECT: The European marketing firm works for the survey company. The survey company pays the marketing firm to sell its data in Europe. (A) would incur a cost on the marketing firm that would be passed onto the survey company. (B) is correct: CRR reduces cost.
Comment: In this setup, anyone who requests data from the S3 bucket must cover the cost of the data transfer and request charges. This approach is ideal for S3 bucket owners who share large datasets with other users or organizations and want to avoid bearing the cost of data transfer. This would be the most direct way to ensure that the survey company's data transfer costs remain minimal while sharing data with the European marketing firm. The marketing firm, as the requester, will pay for the data they access or transfer.
Comment: The most suitable solution for minimizing data transfer costs while sharing data with the European marketing firm is: B. Configure S3 Cross-Region Replication from the company's S3 bucket to one of the marketing firm's S3 buckets.
Comment: Same as Question #44
Comment: A is the correct answer.
Comment: Accidental deletion is the key. Deletion is allowed but MFA deletion ensures that deletion requires an additional step. https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html
Comment: Enable the versioning to ensure restoration in case of accidental deletion and MFA Delete for double verification before deletion.
Comment: Versioning will keep multiple variants of an object in case one is accidentally or intentionally deleted - the previous versions can still be restored. MFA Delete requires additional authentication to permanently delete an object version. This prevents accidental deletion
Comment: B. Enabling MFA on the IAM user credentials adds an extra layer of security to the user authentication process. However, it does not specifically address the concern of accidental deletion of documents in the S3 bucket. C. Adding an S3 Lifecycle policy to deny the delete action during audit dates would prevent intentional deletions during specific time periods. However, it does not address accidental deletions that can occur at any time. D. Using KMS for encryption and restricting access to the KMS key provides additional security for the data stored in the S3 . However, it does not directly prevent accidental deletion of documents in the S3. Enabling versioning and MFA Delete on the S3 (option A) is the most appropriate solution for securing the audit documents. Versioning ensures that multiple versions of the documents are stored, allowing for easy recovery in case of accidental deletions. Enabling MFA Delete requires the use of multi-factor authentication to authorize deletion actions, adding an extra layer of protection against unintended deletions.
Comment: A is answer.
Comment: A is answer.
Comment: A is correct.
Comment: only accidental deletion should be avoided. IAM policy will completely remove their access.hence, MFA is the right choice.
Comment: what about : IAM policies are used to specify permissions for AWS resources, and they can be used to allow or deny specific actions on those resources. { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDeleteObject", "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": [ "arn:aws:s3:::my-bucket/my-object", "arn:aws:s3:::my-bucket" ] } ] }
Comment: only accidental deletion should be avoided. IAM policy will completely remove their access.hence, MFA is the right choice.
Comment: The solution architect should do Option A: Enable the versioning and MFA Delete features on the S3 bucket. This will secure the audit documents by providing an additional layer of protection against accidental deletion. With versioning enabled, any deleted or overwritten objects in the S3 bucket will be preserved as previous versions, allowing the company to recover them if needed. With MFA Delete enabled, any delete request made to the S3 bucket will require the use of an MFA code, which provides an additional layer of security.
Comment: Option B: Enable multi-factor authentication (MFA) on the IAM user credentials for each audit team IAM user account, would not provide protection against accidental deletion. Option C: Adding an S3 Lifecycle policy to the audit team's IAM user accounts to deny the s3:DeleteObject action during audit dates, which would not provide protection against accidental deletion outside of the specified audit dates. Option D: Use AWS Key Management Service (AWS KMS) to encrypt the S3 bucket and restrict audit team IAM user accounts from accessing the KMS key, would not provide protection against accidental deletion.
Comment: A is the right answer
Comment: A is correct
Comment: Enable the versioning and MFA Delete features on the S3 bucket.
Comment: Elasti Cache if for reading common results. The script is looking for new movies added. Read replica would be the best choice.
Comment: • You have a production DB that is taking on a normal load • You want to run a reporting application to run some analytics • You create a read replica to run the new workload there • The prod application is unaffected • Read replicas are used for SELECT (=read) only kind of statements Therefore I believe B to be the better answer. As for "D" - ElastiCache use cases are: 1. Your data is slow or expensive to get when compared to cache retrieval. 2. Users access your data often. 3. Your data stays relatively the same, or if it changes quickly staleness is not a large issue. 1 - Somewhat true. 2 - Not true for our case. 3 - Also not true. The data changes throughout the day. For my understanding, caching has to do with millisecond results, high-performance reads. These are not the issues mentioned in the questions, therefore B.
Comment: I will support this by point to the question : " with the LEAST operational overhead?" Configuring the read replica is much easier than configuring and integrating new service.
Comment: Ans B - as per Gil80 (1 year, 10mth ago) "Selected Answer: B • You have a production DB that is taking on a normal load • You want to run a reporting application to run some analytics • You create a read replica to run the new workload there • The prod application is unaffected • Read replicas are used for SELECT (=read) only kind of statements Therefore I believe B to be the better answer. As for "D" - ElastiCache use cases are: 1. Your data is slow or expensive to get when compared to cache retrieval. 2. Users access your data often. 3. Your data stays relatively the same, or if it changes quickly staleness is not a large issue. 1 - Somewhat true. 2 - Not true for our case. 3 - Also not true. The data changes throughout the day. For my understanding, caching has to do with millisecond results, high-performance reads. These are not the issues mentioned in the questions, therefore B."
Comment: option B for sure, read replica is designed for this very use case, improving performance, on the other hand, enabling multi-AZ improves availability and not performance.
Comment: A. Having multi-AZ database would increase availability, bu not performance. C. Not practical. Huge Operational Overhead. (Solution should be LEAST operational overhead) D. Good for fixed queries with fixed results. not a good fit in this case as script is looking for new results in DB. It has to scan the database. Correct Answer B. Read replica ensure you have dedicated read instance with its own resources.
Comment: Just read from read replica. A: This will make it HA but won't solve any problems C: We want an AWS solution not change the development team's ways of working D: Elasticache is cache of read queries when data doesn't change. It's useless for finding new data.
Comment: Answer C is inconcevable according to LEAST operational overhead? We will exclude answer D because question is about RDS databases and ElastiCache is not. Between answers A and B , A is the most appropriate answer due to 2 foolowing points: - Possible to transfrom a Single-AZ RDS to Multi-AZ - LEAST operational overhead
Comment: It is A , because the scenario mention "single db instance" which is not possible to enable read replica
Comment: Doesn't it become a multi-instance DB when you add a read replica? A can't be because you can't read from the passive replica of a multi-AZ DB.
Comment: lol seriously the person who wrote the answer wants us to fail
Comment: This is what we do in the real world.
Comment: - Cached data might not always be up-to-date, so you need to manage cache expiry and invalidation carefully. - It may require some code changes to implement caching logic in your script. - ElastiCache comes with additional costs, so you should assess the cost implications based on your usage.
Comment: Why not D: While ElastiCache can be relatively easy to set up, it still requires ongoing management, monitoring, and potentially scaling as the dataset and query load grow. This introduces operational overhead that may not align with the goal of minimizing operational work.
Comment: the correct answer should be A, you can't create a read replica on a single-AZ DB instance
Comment: Actualy you can
Comment: a read replica is always fit for these type of scenarios.
Comment: The key requirements are: The script must report a final total during business hours Resolve the issue of inadequate database performance for development tasks when the script is running With the least operational overhead
Comment: A. Modifying the DB to be a Multi-AZ deployment improves high availability and fault tolerance but does not directly address the performance issue during the script execution. C. Instructing the development team to manually export the entries in the database introduces manual effort and is not a scalable or efficient solution. D. While using ElastiCache for caching can improve read performance for common queries, it may not be the most suitable solution for the scenario described. Caching is effective for reducing the load on the database for frequently accessed data, but it may not directly address the performance issue during the script execution. Creating a read replica of the database (option B) provides a scalable solution that offloads read traffic from the primary database. The script can be configured to query the read replica, reducing the impact on the primary database during the script execution.
Comment: For LEAST operational overhead, I recommended to use read replica DB
Comment: Gateway endpoints provide reliable connectivity to Amazon S3 and DynamoDB without requiring an internet gateway or a NAT device for your VPC. It should be option A. https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
Comment: ***CORRECT*** The correct solution is Option A (Configure an S3 gateway endpoint.) A gateway endpoint is a VPC endpoint that you can use to connect to Amazon S3 from within your VPC. Traffic between your VPC and Amazon S3 never leaves the Amazon network, so it doesn't traverse the internet. This means you can access Amazon S3 without the need to use a NAT gateway or a VPN connection. ***WRONG*** Option B (creating an S3 bucket in a private subnet) is not a valid solution because S3 buckets do not have subnets. Option C (creating an S3 bucket in the same AWS Region as the EC2 instances) is not a requirement for meeting the given security regulations. Option D (configuring a NAT gateway in the same subnet as the EC2 instances) is not a valid solution because it would allow traffic to leave the VPC and travel across the Internet.
Comment: Ans A - S3 gateway endpoint: dedicated end-end and private
Comment: A is the correct answer
Comment: it's definitely A
Comment: A. Configure an S3 gateway endpoint. Correct: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html With a gateway endpoint, you can access Amazon S3 from your VPC, without requiring an internet gateway or NAT device for your VPC. Additional you need to configure the route table for the subnet that EC2 stays, but we have the key word here. B. Create an S3 bucket in a private subnet. I am not aware that we can create S3 bucket in certain subnet. C. Create an S3 bucket in the same AWS Region as the EC2 instances. Not enough. Without VPC gateway endpoint, access will through go out to the internet. D. Configure a NAT gateway in the same subnet as the EC2 instances. NAT gateway outbound traffic should also go out to the internet.
Comment: You can access Amazon S3 from your VPC using gateway VPC endpoints. After you create the gateway endpoint, you can add it as a target in your route table for traffic destined from your VPC to Amazon S3. There is no additional charge for using gateway endpoints. Amazon S3 supports both gateway endpoints and interface endpoints. With a gateway endpoint, you can access Amazon S3 from your VPC, without requiring an internet gateway or NAT device for your VPC, and with no additional cost. However, gateway endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a transit gateway. For those scenarios, you must use an interface endpoint, which is available for an additional cost. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
Comment: EC2 to S3 without public interne = S3 gatewat B: Cannot be implemented C: Even if you create EC2 and S3 in same region, without a S3 gateway it will use the public internet D: Makes no sense, NAT gateway in the subnet as EC2 instance to do what?
Comment: A gateway endpoint is a VPC endpoint that you can use to connect to Amazon S3 from within your VPC. Traffic between your VPC and Amazon S3 never leaves the Amazon network, so it doesn't traverse the internet. This means you can access Amazon S3 without the need to use a NAT gateway or a VPN connection
Comment: Answer "A" is correct because an endpoint create a way for the data to travel in the VPC
Comment: Prevent traffic from traversing the internet = Gateway VPC endpoint for S3.
Comment: Configure an S3 gateway endpoint
Comment: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
Comment: B. Creating an S3 in a private subnet restricts direct internet access to the bucket but does not provide a direct and secure connection between the EC2and the S3. The application would still need to traverse the internet to access the S3 API. C. Creating an S3 in the same Region as the EC2 does not inherently prevent traffic from traversing the internet. D. Configuring a NAT gateway allows outbound internet connectivity for resources in private subnets, but it does not provide a direct and secure connection to the S3 service. The traffic from the EC2 to the S3 API would still traverse the internet. The most suitable solution is to configure an S3 gateway endpoint (option A). It provides a secure and private connection between the VPC and the S3 service without requiring the traffic to traverse the internet. With an S3 gateway endpoint, the EC2 can access the S3 API directly within the VPC, meeting the security requirement of preventing traffic from traveling across the internet.
Comment: Configure an S3 gateway endpoint is answer.
Comment: S3 Gateway Endpoint is a VPC endpoint,
Comment: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
Comment: A,D - altho' I stand corrected: D means copying credentials which introduces a security risk... so that means A,C
Comment: A removes the need for a NAT gateway and keeps the connection private, C restricts access to the bucket.
Comment: A: VPC S3 gateway for direct connection (no public internet) to access S3 C: Bucket policy to secure access and only allow the VPC application tier to access it B: Opens up to public D: Not secure to copy credentials E: NAT instance (obsolete now) is not useful for limiting resource access, it's for subnet connections
Comment: no one mentioned the translation issue, "limit access to sth" sounds like limit this but allow others, confusing for non-English speaker.
Comment: ) Configure a VPC gateway endpoint for Amazon S3 within the VPC. C) Create a bucket policy that limits access to only the application tier running in the VPC. The key requirements are secure access to the S3 bucket from EC2 instances in the VPC. A VPC endpoint for S3 allows connectivity from the VPC to S3 without needing internet access. The bucket policy should limit access only to the VPC by whitelisting the VPC endpoint.
Comment: These are correct because "A" and "C" ensure secure access and secure connectivity between the S3 and the EC2 instances
Comment: The key requirements are to provide secure access to the S3 bucket only from the application tier EC2 instances inside the VPC. A VPC gateway endpoint allows private access to S3 from within the VPC without needing internet access. This keeps the traffic secure within the AWS network. The bucket policy should limit access to only the application tier, not make the objects public. This restricts access to the sensitive data to only the authorized application tier.
Comment: The correct options are: A) Configure a VPC gateway endpoint for Amazon S3 within the VPC. C) Create a bucket policy that limits access to only the application tier running in the VPC. The key requirements are secure access to the S3 bucket from EC2 instances in the VPC. A VPC endpoint for S3 allows connectivity from the VPC to S3 without needing internet access. The bucket policy should limit access only to the VPC by whitelisting the VPC endpoint.
Comment: ac is the correct answer, as per my knowledge people are confused with IAM user we can use IAM role for secure access.
Comment: AC is the right answer
Comment: A. This eliminates the need for the traffic to go over the internet, providing an added layer of security. B. It is important to restrict access to the bucket and its objects only to authorized entities. C. This helps maintain the confidentiality of the sensitive user information by limiting access to authorized resources. D. In this case, since the EC2 instances are accessing the S3 bucket from within the VPC, using IAM user credentials is unnecessary and can introduce additional security risks. E. a NAT instance to access the S3 bucket adds unnecessary complexity and overhead. In summary, the recommended steps to provide secure access to the S3 from the application tier running on EC2 inside a VPC are to configure a VPC gateway endpoint for S3 within the VPC (option A) and create a bucket policy that limits access to only the application tier running in the VPC (option C).
Comment: A & C the correct solutions.
Comment: A and C
Comment: A and C
Comment: The key part that many miss out on is 'Combination' The other answers are not wrong but A works with C and not with the rest as they need an internet connection.
Comment: AC is correct
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/s3-private-connection-noauthentication/
Comment: The recommended solution is Option B: Use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production. Use database cloning to create the staging database on-demand. To alleviate the application latency issue, the recommended solution is to use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production, and use database cloning to create the staging database on-demand. This allows the development team to continue using the staging environment without delay, while also providing elasticity and availability for the production application. Therefore, Options A, C, and D are not recommended
Comment: Agree, solution it seems to be the B) 1) Because the company wants "elasticity and availability" as the question mentioned, so I think this leaves us in the two questions related to Aurora discarding the RDS Mysql solution. 2) Accoding AWS documentation (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html) "Aurora cloning is especially useful for quickly setting up test environments using your production data, without risking data corruption"
Comment: Option A: Use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production. Populating the staging database by implementing a backup and restore process that uses the mysqldump utility is not the recommended solution because it involves taking a full export of the production database, which can cause unacceptable application latency. Option C: Use Amazon RDS for MySQL with a Multi-AZ deployment and read replicas for production. Using the standby instance for the staging database is not the recommended solution because it does not give the development team the ability to continue using the staging environment without delay. The standby instance is used for failover in case of a production instance failure, and it is not intended for use as a staging environment.
Comment: Option D: Use Amazon RDS for MySQL with a Multi-AZ deployment and read replicas for production. Populating the staging database by implementing a backup and restore process that uses the mysqqldump utility is not the recommended solution because it involves taking a full export of the production database, which can cause unacceptable application latency.
Comment: Aura MySQL is very fast in comparison to RDS for creating a clone of DB, you can create a even clone of a clone while you still work on your own clone, this will allow the dev team continue working during cloning step. https://aws.amazon.com/blogs/aws/amazon-aurora-fast-database-cloning/
Comment: Answer B: Few Points about Aurora Database Cloning: • Create a new Aurora DB Cluster from an existing one • Faster than snapshot & restore • Uses copy-on-write protocol • Very fast & cost-effective • Useful to create a “staging” database from a “production” database without impacting the production database
Comment: When the question did not say about "cost efficient", always choose Aurora MySQL > RDS MySQL, because AWS can earn more money in Aurora
Comment: I'll go for B AD: looks time consuming as mysqldump is like a table dump C: You cannot use a standby for anything apart from read-only database. This would be an option if dev team was specifically using it for read-only mode. https://aws.amazon.com/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/
Comment: B. With Aurora, you can create a clone of the production database quickly and efficiently, without the need for time-consuming backup and restore processes. The development team can spin up the staging database on-demand, eliminating delays and allowing them to continue using the staging environment without interruption.
Comment: B is the correct
Comment: No mention of cost, so technically both options B & C would work. C. https://aws.amazon.com/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/#:~:text=read%20replicas.-,Amazon%20RDS,-now%20offers%20Multi B.https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html#:~:text=cloning%20works.-,Aurora%20cloning,-is%20especially%20useful
Comment: Option B is the best solution that meets all the requirements: Use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production. Use database cloning to create the staging database on-demand. The key requirements are to: Alleviate application latency caused by database exports Give development immediate access to a staging environment Aurora Multi-AZ replicas improves availability and provides fast failover. Database cloning creates an instantly available copy of the production database that can be used for staging. This avoids any export or restoration del
Comment: A. Populating the staging database through a backup and restore process using the mysqldump utility would still result in delays and impact application latency. B. With Aurora, you can create a clone of the production database quickly and efficiently, without the need for time-consuming backup and restore processes. The development team can spin up the staging database on-demand, eliminating delays and allowing them to continue using the staging environment without interruption. C. Using the standby instance for the staging database would not provide the development team with the ability to use the staging environment without delay. The standby instance is designed for failover purposes and may not be readily available for immediate use. D. Relying on a backup and restore process using the mysqldump utility would still introduce delays and impact application latency during the data population phase.
Comment: With Amazon Aurora MySQL, creating a staging database using database cloning is an easy process. Using database cloning will eliminate the performance issues that occur when a full export is done, and the new database is created. In addition, Amazon Aurora's high availability is provided through Multi-AZ deployment, and read replicas can be used to serve the heavy read traffic without affecting the production database. This solution provides better scalability, elasticity, and availability than the current architecture.
Comment: Answer B:
Comment: https://aws.amazon.com/blogs/aws/amazon-aurora-fast-database-cloning/
Comment: Database cloning is the best answer
Comment: Database cloning is right answer here.
Comment: Option B is right. You can not access Standby instance for Read in RDS Multi-AZ Deployments.
Comment: In a RDS Multi-AZ deployment, you can use the standby instance for read-only purposes, such as running queries and reporting. This is known as a "read replica." You can create one or more read replicas of a DB instance and use them to offload read traffic from the primary instance. https://aws.amazon.com/about-aws/whats-new/2018/01/amazon-rds-read-replicas-now-support-multi-az-deployments/
Comment: This is correct, stand by instances cannot be used for read/write and is for failover targets. Read Replicas can be used for that so B is correct.
Comment: why not C
Comment: Also the company wants "elasticity and availability" as the question mentioned, so I think this leaves us in the two questions related to Aurora discarding the RDS Mysql solution.
Comment: Because standby instances are not writable, and at least from my side I occasionally have used the staging database for bug replication. So being able to write might be a thing to consider.
Comment: You don't need to write anything as they are only pulling the reports. (READ requests) The Best answer here is C
Comment: Option C Dynamo DB is a NoSQL-JSON supported
Comment: also Use an AWS Lambda - serverless - less operational overhead
Comment: A. Configuring EMR and an Aurora DB cluster for this use case would introduce unnecessary complexity and operational overhead. EMR is typically used for processing large datasets and running big data frameworks like Apache Spark or Hadoop. B. While using S3 event notifications and SQS for decoupling is a good approach, using EC2 to process the data would introduce operational overhead in terms of managing and scaling the EC2. D. Using EventBridge and Kinesis Data Streams for this use case would introduce additional complexity and operational overhead compared to the other options. EventBridge and Kinesis are typically used for real-time streaming and processing of large volumes of data. In summary, option C is the recommended solution as it provides a serverless and scalable approach for processing uploaded files using S3 event notifications, SQS, and Lambda. It offers low operational overhead, automatic scaling, and efficient handling of varying demand. Storing the resulting JSON file in DynamoDB aligns with the requirement of saving the data for later analysis.
Comment: Ans C - as per cookieMr (1 yr, 2 mth ago) "...In summary, option C is the recommended solution as it provides a serverless and scalable approach for processing uploaded files using S3 event notifications, SQS, and Lambda. It offers low operational overhead, automatic scaling, and efficient handling of varying demand. Storing the resulting JSON file in DynamoDB aligns with the requirement of saving the data for later analysis."
Comment: Option C, fulfills the least operational overhead condition.
Comment: B where we use EC2 instances for processing would be ideal in situations where runtime is > 15 minutes. However the question mentions 'simple processing', hence we go for Lambda.
Comment: LEAST operational overhead A: EMR is massive programming effort for this B: EC2 is considerable overhead D: Nice solution but why would you use Kinesis as there is no streaming scenario here C: Simplest and all managed services so least operational overhead compared to other options
Comment: Option C is the best solution that meets the requirements with the least operational overhead: Configure Amazon S3 to send event notification to SQS queue Use Lambda function triggered by SQS to process each file Store output JSON in DynamoDB This leverages serverless components like S3, SQS, Lambda, and DynamoDB to provide automated file processing without needing to provision and manage servers. SQS queues the notifications and Lambda scales automatically to handle spikes and drops in file uploads. No EMR cluster or EC2 Fleet is needed to manage.
Comment: C: Lambdas are made for that
Comment: C is best
Comment: Option C is the best solution that meets the requirements with the least operational overhead: Configure Amazon S3 to send event notification to SQS queue Use Lambda function triggered by SQS to process each file Store output JSON in DynamoDB This leverages serverless components like S3, SQS, Lambda, and DynamoDB to provide automated file processing without needing to provision and manage servers. SQS queues the notifications and Lambda scales automatically to handle spikes and drops in file uploads. No EMR cluster or EC2 Fleet is needed to manage.
Comment: Option C is correct - Dynamo DB is a NoSQL-JSON supported
Comment: SQS + LAMDA + JSON >>>>>> Dynamo DB
Comment: The option C is right answer.
Comment: can someone explain why SQS? it's a poll-based messaging, does it guarantee reacting the event asap?
Comment: Dynamo DB is a NoSQL-JSON supported
Comment: Option C, Configuring Amazon S3 to send an event notification to an Amazon Simple Queue Service (SQS) queue and using an AWS Lambda function to read from the queue and process the data, would likely be the solution with the least operational overhead. AWS Lambda is a serverless computing service that allows you to run code without the need to provision or manage infrastructure. When a new file is uploaded to Amazon S3, it can trigger an event notification which sends a message to an SQS queue. The Lambda function can then be set up to be triggered by messages in the queue, and it can process the data and store the resulting JSON file in Amazon DynamoDB.
Comment: Using a serverless solution like AWS Lambda can help to reduce operational overhead because it automatically scales to meet demand and does not require you to provision and manage infrastructure. Additionally, using an SQS queue as a buffer between the S3 event notification and the Lambda function can help to decouple the processing of the data from the uploading of the data, allowing the processing to happen asynchronously and improving the overall efficiency of the system.
Comment: Option C as JSON is supported by DynamoDB. RDS or AuroraDB are not suitable for JSON data. A - Because this is not a Bigdata analytics usecase.
Comment: The solutions architect should recommend option D: Create read replicas for the database. Configure the read replicas with the same compute and storage resources as the source database. Creating read replicas allows the application to offload read traffic from the source database, improving its performance. The read replicas should be configured with the same compute and storage resources as the source database to ensure that they can handle the read workload effectively.
Comment: Ans D - can't be C because we don't know how much CPU write/read respectively consumes; we'll have to monitor to find out...
Comment: D makes the most sense.
Comment: Keyword: "separate read traffic from write traffic" = Read Replica = Option A and B are not the correct answer. Option C: Why would you try to have half the resource for read replicas ?. It must be equal resources to ensure read load can be served consistently. Correct Answer is D: Read replica with same compute power as source database instance.
Comment: By default, a read replica is created with the same storage type as the source DB instance. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
Comment: A: This will not have any change as you are still reading from same instance as you are writing to B: Not possible (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) C: Why would you do that even if that was possible? No one asked to save on cost D: Read replicas are normally for handling read-only traffic
Comment: In a Multi-AZ deployment, the standby instance is kept in sync with the primary instance and is used for failover purposes only. You cannot read data from the standby instance in a Multi-AZ deployment. If you need to offload read traffic from the primary instance, you can create one or more Read Replicas. Read Replicas are read-only copies of your database that can be used to offload read traffic from the primary instance, which can help improve performance
Comment: D. Configuring the read replicas with the same compute and storage resources as the source database ensures that they can handle the read workload efficiently and provide the required performance boost.
Comment: Both B and D would work. Amazon RDS now offers Multi-AZ deployments with readable standby instances (also called Multi-AZ DB cluster deployments) . You should consider using Multi-AZ DB cluster deployments with two readable DB instances if you need additional read capacity in your Amazon RDS Multi-AZ deployment and if your application workload has strict transaction latency requirements such as single-digit milliseconds transactions. https://aws.amazon.com/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/#:~:text=read%20replicas.-,Amazon%20RDS,-now%20offers%20Multi
Comment: The best solution is to create read replicas for the database and configure them with the same compute and storage resources as the source database. The key requirements are to quickly optimize performance by isolating reads from writes. Read replicas allow read-only workloads to be directed to one or more replicas of the source RDS instance. This separates reporting or analytics queries from transactional workloads. The read replicas should have the same compute and storage as the source to provide equivalent performance for reads. Scaling down the replicas would limit read performance. Using Multi-AZ alone does not achieve read/write separation. The secondary AZ instance is for disaster recovery, not performance.
Comment: Read replica + Same resources as we may need to turn replica to primary in few cases
Comment: A. In a Multi-AZ deployment, a standby replica of the database is created in a different AZ for high availability and automatic failover purposes. However, serving read requests from the primary AZ alone would not effectively separate read and write traffic. Both read and write traffic would still be directed to the primary database instance, which might not fully optimize performance. B. The secondary instance in a Multi-AZ deployment is intended for failover and backup purposes, not for actively serving read traffic. It operates in a standby mode and is not optimized for handling read queries efficiently. C. Configuring the read replicas with half of the compute and storage resources as the source database might not be optimal. It's generally recommended to configure the read replicas with the same compute and storage resources as the source database to ensure they can handle the read workload effectively. D. Configuring the read replicas with the same compute and storage resources as the source database ensures that they can handle the read workload efficiently and provide the required performance boost.
Comment: D meets the requiremets.
Comment: Option C suggests creating read replicas for the database and configuring them with half of the compute and storage resources as the source database. This is a better option as it allows read traffic to be offloaded from the primary database, separating read traffic from write traffic. Configuring the read replicas with half the resources will also save on costs.
Comment: If the source database is already 40% full, the read replica's performance will degrade as it is @ 80% capacity. This will not optimize the apps performance.
Comment: Err, just curious, what if the production database is 51% full? Your half storage read replica would explode…?
Comment: Can anyone explain why B is not an option?
Comment: CHATGPT says: To optimize the application's performance and separate read traffic from write traffic, the solutions architect should recommend creating read replicas for the database and configuring them to serve read requests. Option C and D both suggest creating read replicas, but option D is a better choice because it configures the read replicas with the same compute and storage resources as the source database. Option A and B suggest changing the existing database to a Multi-AZ deployment, which would provide high availability by replicating the database across multiple Availability Zones. However, it would not separate read and write traffic, so it is not the best solution for optimizing application performance in this scenario.
Comment: Multi-AZ: Synchronous replication occurs, meaning that synchronizing data between DB instances immediately can slow down application's performance. But this method increases High Availability. Read Replicas: Asynchronous replication occurs, meaning that replicating data in other moments rather than in the writing will maintain application's performance. Although the data won't be HA as Multi-AZ kind of deployment, this method increases Scalability. Good for read heavy workloads.
Comment: You can create up to 15 read replicas from one DB instance within the same Region. For replication to operate effectively, each read replica should have the same amount of compute and storage resources as the source DB instance. If you scale the source DB instance, also scale the read replicas.
Comment: I think for RDS it is 5 read replicas. 15 is for aurora serverless
Comment: Option D
Comment: D is correct
Comment: What the policy means: 1. Allow termination of any instance if user's source IP address is 100.100.254. 2. Deny termination of instances that are not in the us-east-1 Combining this two, you get: “Allow instance termination in the us-east-1 region if the user's source IP address is 10.100.100.254. Deny termination operation on other regions.”
Comment: Nice explanation. Thanks
Comment: C is correct. 0.0/24 , the following five IP addresses are reserved: 0.0: Network address. 0.1: Reserved by AWS for the VPC router. 0.2: Reserved by AWS. The IP address of the DNS server is the base of the VPC network range plus two. ... 0.3: Reserved by AWS for future use. 0.255: Network broadcast address.
Comment: A good explanation!
Comment: Ans C - must be in us-east-1 region and CIDR address is in allowable range (/24)
Comment: The first rule allows users with the specified IP CIDR to terminate instances, and the second rule specifies that the region must be us-east-1 for the termination process to be allowed, hence C is the correct answer.
Comment: policy allow us-east-1 and with the specific IP address in the range
Comment: C for sure
Comment: D. Users cannot terminate an EC2 instance in the us-east-1 region when the user's source IP is 10.100.100.254. This option corresponds to the second statement in the policy, where all EC2 actions in the "us-east-1" region are denied permission when the user's source IP is "10.100.100.254".
Comment: but it says "StringNotEquals" meaning everything is denied apart from us-east-1
Comment: Clearly the answer is C. D is 'Deny' 'String NOT equal' == only allow us-east-1
Comment: Here is how I interpreted this first part: terminate instance is allowed for the given CIDR block second part: deny all ec2 actions when region is not us-east-1 so second part is like double negative which means allow for us-east-1 region You combine both (remember deny always take priority which is why this is written in double negative) and you get: [allow us-east-region1 to do any action on ec2] when [action is terminate instance and CIDR block is match] so C is the answer D is there to confuse you with the double negative
Comment: Deny takes precedence over Allow. Thus the flow is as follows: IF region of the EC2 instance is not "us-east-1" -> Deny ELSE if request is coming from 10.100.100.0/24 -> Allow ELSE: implicit deny (what is not allowed is denied)
Comment: if IP = 10.100.100.0/24 allow terminate EC2 Else Deny EC2 termination permission - with the condition "String NOT equal" to us-east-1 Answer C
Comment: The first statement allows users to terminate EC2 instances (ec2:TerminateInstances) from any IP address within the range 10.100.100.0/24. The second statement denies users the ability to perform any EC2 actions (ec2:*) in any region other than us-east-1. So, the correct interpretation is: D. Users cannot terminate an EC2 instance in the us-east-1 Region when the user's source IP is 10.100.100.254
Comment: D denies "the ability to perform any actions in any region OTHER than us-east-1". Thus the user CAN terminate instances IN us-east-1. Thus C.
Comment: C because the explicit deny blocks other regions than us-east-1
Comment: The first statement is a subset of the second statement.
Comment: ans D - This policy denies EC2 instance termination for users with the source IP address 10.100.100.254 in the us-east-1 Region.
Comment: D is not because of Deny & NOT Equals
Comment: I went for C for obvious reasons Wondering though; this policy also allows to terminate EC2 instances in US-east-1 even if your source IP is not the 10.100.100.254, right? The idea is that since I do not deny this for the other source IP addresses, the Allow action is a obsolete?
Comment: D. Create an Amazon FSx for Windows File Server file system on AWS and set the Active Directory domain for authentication. Amazon FSx for Windows File Server is a fully managed file storage service that is designed to be used with Microsoft Windows workloads. It is integrated with Active Directory for access control and is highly available, as it stores data across multiple availability zones. Additionally, FSx can be used to migrate data from on-premises Microsoft Windows file servers to the AWS Cloud. This makes it a good fit for the requirements described in the question.
Comment: A. EFS does not provide native integration with AD for access control. While you can configure EFS to work with AD, it requires additional setup and is not as straightforward as using a dedicated Windows file system like FSx for Windows File Server. B. It may introduce additional complexity for this use case. Creating an SMB file share using AWS Storage Gateway would require maintaining the gateway and managing the synchronization between on-premises and AWS storage. C. S3 does not natively provide the SMB file protocol required for MS SharePoint and Windows shared file storage. While it is possible to mount an S3 as a volume using 3rd-party tools or configurations, it is not the recommended. D. FSx for Windows File Server is a fully managed, highly available file storage service that is compatible with MSWindows shared file storage requirements. It provides native integration with AD, allowing for seamless access control and authentication using existing AD user accounts.
Comment: Ans D - Amazon FSx for Windows; set Active Directory I was initially going for A, but EFS doesn't provide native integration with AD for access control; in any event, its Windows so the obvious answer is FSx
Comment: D for sure
Comment: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/aws-ad-integration-fsxW.html "When you create a file system with Amazon FSx, you join it to your Active Directory domain to provide user authentication and file- and folder-level access control."
Comment: D. Create an Amazon FSx for Windows File Server file system on AWS and set the Active Directory domain for authentication. Amazon FSx for Windows File Server is a fully managed file storage service that is designed to be used with Microsoft Windows workloads. It is integrated with Active Directory for access control and is highly available, as it stores data across multiple availability zones. Additionally, FSx can be used to migrate data from on-premises Microsoft Windows file servers to the AWS Cloud. This makes it a good fit for the requirements described in the question.
Comment: Microsoft Windows shared file storage = Amazon FSx for Windows File Server
Comment: The best solution that satisfies the requirements is D) Create an Amazon FSx for Windows File Server file system on AWS and set the Active Directory domain for authentication. The key requirements are: Shared Windows file storage for SharePoint High availability Integrated Active Directory authentication
Comment: D is correct. FSx is for windows and supports AD authentication
Comment: Why not B? Migrating the workload? Maybe is needed a hybrid cloud solution
Comment: One solution that can satisfy the mentioned requirements is to use Amazon FSx for Windows File Server. Amazon FSx is a fully managed service that provides highly available and scalable file storage for Windows-based applications. It is designed to be fully integrated with Active Directory, which allows you to use your existing domain users and groups to control access to your file shares. Amazon FSx provides the ability to migrate data from on-premises file servers to the cloud, using tools like AWS DataSync, Robocopy or PowerShell. Once the data is migrated, you can continue to use the same tools and processes to manage and access the file shares as you would on-premises. Amazon FSx also provides features such as automatic backups, data encryption, and native multi-Availability Zone (AZ) deployments for high availability. It can be easily integrated with other AWS services, such as Amazon S3, Amazon EFS, and AWS Backup, for additional functionality and backup options.
Comment: FSx is for Windows
Comment: Option D
Comment: Im going for D as the answer because FXs is compatible with windows
Comment: Answer is D
Comment: D is correct
Comment: Window only available for using FSx
Comment: Answer is D. Lustre in the question is only available as FSx https://aws.amazon.com/fsx/lustre/
Comment: Option D. Create an Amazon FSx for Lustre file system. Attach the file system to the origin server. Connect the application server to the file system. Amazon FSx for Lustre is a fully managed file system that is designed for high-performance workloads, such as gaming applications. It provides a high-performance, scalable, and fully managed file system that is optimized for Lustre clients, and it is fully integrated with Amazon EC2. It is the only option that meets the requirements of being fully managed and able to support Lustre clients.
Comment: D, self explanatory.
Comment: the question is missing some text i think.... as none of the answers really solve the equation. if the answer is D, how is the on prem infrastructure accessing Lustre in AWS? either way the only possible option it could be is D, so D it is.
Comment: Sorry but what is origin server in this context, does it mean AWS server or premise??
Comment: D: Lustre is key requirement AB: No support for Lustre C: Cannot just configure EFS to support Lustre file system
Comment: Option D. Create an Amazon FSx for Lustre file system. Attach the file system to the origin server. Connect the application server to the file system. Amazon FSx for Lustre is a fully managed file system that is designed for high-performance workloads, such as gaming applications. It provides a high-performance, scalable, and fully managed file system that is optimized for Lustre clients, and it is fully integrated with Amazon EC2. It is the only option that meets the requirements of being fully managed and able to support Lustre clients.
Comment: Lustre clients = Amazon FSx for Lustre file system
Comment: The correct solution is D) Create an Amazon FSx for Lustre file system. Attach the file system to the origin server. Connect the application server to the file system. The key requirements are: Shared storage solution Support Lustre clients Fully managed service Amazon FSx for Lustre provides a fully managed file system that is optimized for Lustre workloads. It allows Lustre clients to seamlessly connect to the file system.
Comment: Sorry, but I disagree with everyone. The question states "a gaming application that is hosted in an on-premises data center". Option D does not address this and cannot to my knowledge address it. Thus: A. Create an AWS Storage Gateway file gateway. Create a file share that uses the required client protocol. Connect the application server to the file share. By using AWS Storage Gateway in file gateway mode, you can extend your on-premises data center storage into the AWS cloud. The file share created on AWS Storage Gateway can use the necessary client protocol (such as Lustre), which would allow the Lustre clients in your on-premises data center to access the data stored on AWS Storage Gateway. This solution enables you to use Lustre clients to access data, while still keeping the gaming application hosted in your on-premises data center. AWS Storage Gateway provides a fully managed solution for this hybrid scenario, allowing seamless integration between on-premises and AWS cloud storage.
Comment: mate if you have an aws service that is meant to be used for this task, there is simply not discussion, is more simple, is more cheap and better option
Comment: So, I think that the FSx File Gateway is currently only available for Windows? I don't think Lustre is part of this offering yet as of 8/8/2023
Comment: "The file share created on AWS Storage Gateway can use the necessary client protocol (such as Lustre)", no it can use only NFS or SMB. But NOT Lustre.
Comment: Content of "Amazon FSx for Lustre" at this link https://aws.amazon.com/fsx/lustre/ . Focus at image, section: "On-premises clients".
Comment: A. Lustre client access is not supported by AWS Storage Gateway file gateway. B. Creating a Windows file share on an EC2 Windows instance is suitable for Windows-based file sharing, but it does not provide the required Lustre client access. Lustre is a high-performance parallel file system primarily used in high-performance computing (HPC) environments. C. EFS does not natively support Lustre client access. Although EFS is a managed file storage service, it is designed for general-purpose file storage and is not optimized for Lustre workloads. D. Amazon FSx for Lustre is a fully managed file system optimized for high-performance computing workloads, including Lustre clients. It provides the ability to use Lustre clients to access data in a managed and scalable manner. By choosing this option, the company can benefit from the performance and manageability of Amazon FSx for Lustre while meeting the requirement of Lustre client access.
Comment: https://aws.amazon.com/fsx/lustre/?nc1=h_ls#:~:text=Amazon%20FSx%20for%20Lustre%20provides%20fully%20managed%20shared%20storage%20with%20the%20scalability%20and%20performance%20of%20the%20popular%20Lustre%20file%20system.
Comment: Option D. Create an Amazon FSx for Lustre file system. Attach the file system to the origin server. Connect the application server to the file system. BUT the onprem server couldn't view and have good perf with the EFS, so the question is an absurd !
Comment: seriously? it spells out "Lustre" for you
Comment: D is the most logical solution. But still the app is OnPrem so AWS Fx for Lustre is not enough to connect the storage to the app, we'll need a File Gateway to use with the FSx Lustre
Comment: D is correct
Comment: C makes a better sense. Between C (S3) and D (EBS), S3 is highly available with LEAST operational overhead.
Comment: Agree, also the data in EBS will be accessible only to the EC2 instance and that is not as available as S3 would be.
Comment: Correct Answer is C: EBS is not highly available
Comment: EBS volumes are not Multi-AZ. EBS io2 types are multi-attach within the same AZ. EFS is multi-AZ
Comment: Per AWS: "Amazon EBS volumes are designed to be highly available, reliable, and durable" https://aws.amazon.com/ebs/features/
Comment: EBS is Highly Available as it stores in multi AZ and S3 is regional.
Comment: This is false... S3 is Multi AZ and EBS is only replicated WITHIN an AZ by default.
Comment: EBS also has Multi-AZ capability, but it does not replicate the data across multiple availability zones by default. When Multi-AZ is enabled, it creates a replica of the EBS volume in a different availability zone and automatically failover to the replica in case of a failure. However, this requires additional configuration and management. In comparison, Amazon S3 automatically replicates data across multiple availability zones without any additional configuration. Therefore, storing the data on Amazon S3 provides a simpler and more efficient solution for high availability.
Comment: This is false. There is no AWS-provided functionality that will replicate EBS volumes across AZs. There are 3rd-party solutions to this, but that's not what's being asked here. EBS is only replicated WITHIN an AZ by default.
Comment: S3 is also highly available. Within the region, but still. Multi-AZ = HA.
Comment: Yes it is!
Comment: C is the most efficient.
Comment: AWS KMS: Provides a managed service for secure key storage and encryption/decryption operations. This eliminates the need to manage encryption/decryption logic within the application itself. Customer Managed Key: The company maintains control over the key, ensuring security. EC2 Role Permissions: Granting permissions to the EC2 role allows the application to use KMS for encryption/decryption without managing individual credentials. Amazon S3: Offers highly available and scalable storage for the encrypted certificates. S3 is generally cheaper than EBS for data that is not frequently accessed.
Comment: C for sure
Comment: S3: highly available EBS: lower latency
Comment: "Amazon S3 is an object storage service that can store large volumes of unstructured data, whereas Amazon EBS is a block storage service that is ideally suited for durable, low-latency data storage associated with EC2 instances." https://www.tutorialspoint.com/difference-between-amazon-s3-and-amazon-ebs#:~:text=In%20conclusion%2C%20Amazon%20S3%20is,storage%20associated%20with%20EC2%20instances. Seems like D to me. S3 is for large data, EBS is ec2 specific.
Comment: The language is confusing over here so I'm going by process of elimination A: Wrong because manual operation and fine grained IAM is overhead B: What? D: Between C and D S3 is more HA than EFS so C wins
Comment: Sorry meant EBS, not EFS for D D: Between C and D, S3 is more HA than EBS. So C wins
Comment: I would select D. you can mount a single Amazon Elastic Block Store (EBS) volume to multiple Docker containers running on the same Amazon Elastic Compute Cloud (EC2) instance. . you can store data from a container running on Amazon Elastic Compute Cloud (EC2) to an Amazon Simple Storage Service (S3) bucket. One way to do this is to use the aws s3 cp command in the command line of the EC2 instance.
Comment: A - does not mention storing the encrypted data at all (though that is a requirement), also involves manual action which is surely NOT "least operational effort" B - Doesn't make any sense C - Yes, S3 meets the requirements and is easy to access from containerized app D - EBS volumes are mounted to the container host, but data is created on containers
Comment: A is OK secrets manager: - is highly available - you can store custom secrets in it like certificate - automatically encrypts secrets at rest, and can be configured for encryption in transit - downloading certificate from it is less operational overhead than decrypting it manually with KMS key arguments againts it that this is more manual than C and D? this manual step is necessary measure and can't be omitted in other options C and D have this "store the encrypted data in..." to store encrypted certificate you have to: log in to instance, get kms key, get certificate, encrypt it, and load that data this is more operational overhead
Comment: "Least operational overhead" and "manually" (as in A) usually don't go together. Also, A does not say anything about storing the data (which is a requirement). "C and D have this 'store the encrypted data in'" yes, exactly, the encrypted data, NOT the certificate. You encrypt data with the certificate, and you want to store THAT encrypted data.
Comment: "C" is more correct because S3 is more efficient and cheaper to store data like certificates, like this case. Also Option D involves using Amazon Elastic Block Store (Amazon EBS) volumes, which is not typically used for storing certificates and may introduce unnecessary complexity and operational overhead.
Comment: confused between EBS and S3, both are HA, but location?
Comment: C. when it comes to availability, Amazon S3 is generally more highly available than Amazon EBS because S3 replicates data across multiple AZs by default, providing greater resilience to failures. However, the choice between S3 and EBS depends on your specific use case and whether you need block storage for EC2 instances (EBS) or object storage for storing and retrieving data (S3).
Comment: I selected D, even though S3 has high availability to 11 9's. The question started with EC2 Instance. EBS provides block level storage that is attached to EC2 Instances. They are also designed for High Availability.
Comment: Option C is the best solution that meets all the requirements with the least operational overhead: Use AWS KMS customer managed key for encryption Allow EC2 instance role access to use the KMS key Store encrypted data in Amazon S3
Comment: All data within EBS is stored in equally sized blocks. This system offers some performance advantages over traditional storage, and generally boasts lower latency, too. This would meet the near real time requirement over the S3 option
Comment: NAT Instances - OUTDATED BUT CAN STILL APPEAR IN THE EXAM! However, given that A provides the newer option of NAT Gateway, then A is the correct answer. B would be correct if NAT Gateway wasn't an option.
Comment: NAT instance or NAT Gateway always created in public subnet to provide internet access to private subnet. In option B. they are creating NAT Instance in private subnet which is not correct.
Comment: The correct answer is option A. To enable Internet access for the private subnets, the solutions architect should create three NAT gateways, one for each public subnet in each Availability Zone (AZ). NAT gateways allow private instances to initiate outbound traffic to the Internet but do not allow inbound traffic from the Internet to reach the private instances. The solutions architect should then create a private route table for each AZ that forwards non-VPC traffic to the NAT gateway in its AZ. This will allow instances in the private subnets to access the Internet through the NAT gateways in the public subnets.
Comment: Ans A - it can only be A or B and NAT Gateways are preferred over NAT Instances.
Comment: the correct answer is A, to connect a private subnet to the internet using internet gateways is irrelevant, you have to use either NAT gateway or NAT instance, and NAT gateway is the better choice.
Comment: Nat instances can do the same except it's not cost effective also it need a lot of managment, going with nat gateways makes more sense
Comment: in Azure there is 1 NAT GW multi AZ, 1 per network, I think this is example for AWS to change
Comment: But in AWS a NAT GW is attached to a subnet, and a subnet resides in a single AZ. Can't create multi-AZ NAT GW without changing whole architecture. You CAN use one NAT GW from multiple subnets in multiple AZs I think, but then it would not be HA.
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html
Comment: The best solution is to create a NAT gateway in each public subnet (one per availability zone), and update the route tables for the private subnets to send internet traffic to the NAT gateway. NAT gateways allow private subnets to access the internet for things like software updates, without exposing those instances directly to the internet. An egress-only internet gateway would allow outbound access, but also allow inbound internet traffic, which is not desired for the private subnets.
Comment: "Egress" means outbound connection, remove D. "Second gateway", remove C. Now has only A and B. The different between A versus B is "1 NAT gateway, 1 for public subnet in each AZ" (A) and "1 NAT gateway, 1 for private subnet in each AZ" (B). Choose A.
Comment: By creating a NAT gateway in each public subnet, the private subnets can route their Internet-bound traffic through the NAT gateways. This allows EC2 in the private subnets to download software updates and access other resources on the Internet. Additionally, a separate private route table should be created for each AZ. The private route tables should have a default route that forwards non-VPC traffic (0.0.0.0/0) to the corresponding NAT gateway in the same AZ. This ensures that the private subnets use the appropriate NAT gateway for Internet access. B is incorrect because NAT instances require manual management and configuration compared to NAT gateways, which are a fully managed service. NAT instances are also being deprecated in favor of NAT gateways. C is incorrect because creating a second internet gateway on a private subnet is not a valid solution. Internet gateways are associated with public subnets and cannot be directly associated with private subnets. D is incorrect because egress-only internet gateways are used for IPv6 traffic.
Comment: NAT Gateway will be created Public Subnet and Provide access to Private Subnet
Comment: A is correct. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html
Comment: Now NAT Instances is avoided by AWS. Then choose the NAT Gateway
Comment: A: NAT Gateway
Comment: NAT Gateway - AWS-managed NAT, higher bandwidth, high availability, no administration
Comment: You should create 3 NAT gateways, but not in the public subnet. So, even NAT instance is already deprecated, is the right answer in this case, since it's relate to create in a private subnet, not public.
Comment: Refer: https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-gateway-overview Should be A.
Comment: Answer and HOW-TO B. Install an AWS DataSync agent in the on-premises data center. E. Use AWS DataSync to create a suitable location configuration for the on-premises SFTP server. To automate the process of transferring the data from the on-premises SFTP server to an EC2 instance with an EFS file system, you can use AWS DataSync. AWS DataSync is a fully managed data transfer service that simplifies, automates, and accelerates transferring data between on-premises storage systems and Amazon S3, Amazon EFS, or Amazon FSx for Windows File Server. To use AWS DataSync for this task, you should first install an AWS DataSync agent in the on-premises data center. This agent is a lightweight software application that you install on your on-premises data source. The agent communicates with the AWS DataSync service to transfer data between the data source and target locations.
Comment: Next, you should use AWS DataSync to create a suitable location configuration for the on-premises SFTP server. A location represents a data source or a data destination in an AWS DataSync task. You can create a location for the on-premises SFTP server by specifying the IP address, the path to the data, and the necessary credentials to access the data. Once you have created the location configuration for the on-premises SFTP server, you can use AWS DataSync to transfer the data to the EC2 instance with the EFS file system. AWS DataSync handles the data transfer process automatically and efficiently, transferring the data at high speeds and minimizing downtime.
Comment: Explanation of other options A. Launch the EC2 instance into the same Availability Zone as the EFS file system. This option is not wrong, but it is not directly related to automating the process of transferring the data from the on-premises SFTP server to the EC2 instance with the EFS file system. Launching the EC2 instance into the same Availability Zone as the EFS file system can improve the performance and reliability of the file system, as it reduces the latency between the EC2 instance and the file system. However, it is not necessary for automating the data transfer process.
Comment: C. Create a secondary Amazon Elastic Block Store (Amazon EBS) volume on the EC2 instance for the data. This option is incorrect because Amazon EBS is a block-level storage service that is designed for use with Amazon EC2 instances. It is not suitable for storing large amounts of data that need to be accessed by multiple EC2 instances, like in the case of the NFS-based file system on the on-premises SFTP server. Instead, you should use Amazon EFS, which is a fully managed, scalable, and distributed file system that can be accessed by multiple EC2 instances concurrently.
Comment: D. Manually use an operating system copy command to push the data to the EC2 instance. This option is not wrong, but it is not the most efficient or automated way to transfer the data from the on-premises SFTP server to the EC2 instance with the EFS file system. Manually transferring the data using an operating system copy command would require manual intervention and would not scale well for large amounts of data. It would also not provide the same level of performance and reliability as a fully managed service like AWS DataSync.
Comment: **A**. Launch the EC2 instance into the same Availability Zone as the EFS file system. Makes sense to have the instance in the same AZ the EFS storage is. **B**. Install an AWS DataSync agent in the on-premises data center. The DataSync with move the data to the EFS, which already uses the EC2 instance (see the info provided). No more things are required... C. Create a secondary Amazon Elastic Block Store (Amazon EBS) volume on the EC2 instance for the data. This secondary EBS volume isn't required... the data should be move on to EFS... D. Manually use an operating system copy command to push the data to the EC2 instance. Potentially possible (instead of A), BUT the "automate this task" premise goes against any "manually" action. So, we should keep A. E. Use AWS DataSync to create a suitable location configuration for the on-premises SFTP server. I don't get the relationship between DataSync and the configuration for SFTP "on-prem"! Nonsense. So, anwers are A&B
Comment: Just go to AWS Console, to DataSync and choose "Create Location Configuration". Locations configurations are endpoints used in DataSync task. A location can be the source endpoint of the task, e.g. a NFS on-premise filesystem. So E is helping in the automation process. A is not even part of this automation process, it is a solution already agreed to have EC2 with EFS, how you connect EC2 to EFS is not part of the solution!
Comment: CORRECT ANSWER: B&E Steps 4 &5 https://aws.amazon.com/datasync/getting-started/?nc1=h_ls
Comment: will A,B work without E?
Comment: E is correct https://aws.amazon.com/blogs/storage/migrating-storage-with-aws-datasync/
Comment: Use AWS Transfer Family instead of DataSync for SFTP. So E seems incorrect. When do I use AWS DataSync and when do I use AWS Transfer Family? A: If you currently use SFTP to exchange data with third parties, AWS Transfer Family provides a fully managed SFTP, FTPS, FTP, and AS2 transfer directly into and out of Amazon S3, while reducing your operational burden. If you want an accelerated and automated data transfer between NFS servers, SMB file shares, Hadoop clusters, self-managed or cloud object storage, AWS Snowcone, Amazon S3, Amazon EFS, and Amazon FSx, you can use AWS DataSync. DataSync is ideal for customers who need online migrations for active data sets, timely transfers for continuously generated data, or replication for business continuity.
Comment: A, B for sure
Comment: Ans A,B - hint: "The server must be hosted on an Amazon EC2 instance that uses an Amazon Elastic File System (Amazon EFS) file system" then use DataSync on-prem
Comment: option E is not valid because AWS DataSync does not support SFTP as a location configuration. Instead, you would need to use AWS Transfer Family for SFTP transfers.
Comment: BE is correct
Comment: let DataSync work it all out - AWS DataSync can create a suitable location configuration for an on-premises SFTP server.
Comment: B and E is the most logical solution, launching the instance in the same AZ as the EFS is not cruicial, C and D negate the automation part and the part where it says that we need to use EFS.
Comment: I don't think E is correct. You create an EC2, and DataSync to migrate the NFS to EFS. That's it. You don't need to migrate anything on the on-presmise sftp server
Comment: A could be the right choice but here have to choose 2 options so alone with AB and with E it won't work so correct combination is BE
Comment: BE for sure
Comment: did think AB and now im thinking B and E. the questions and answers seem a bit vague like something is missing but have a look at the info on the AWS page. Use Datasync for migrations between NFS servers. Q: When do I use AWS DataSync and when do I use AWS Transfer Family? A: If you currently use SFTP to exchange data with third parties, AWS Transfer Family provides a fully managed SFTP, FTPS, FTP, and AS2 transfer directly into and out of Amazon S3, while reducing your operational burden. If you want an accelerated and automated data transfer between NFS servers, SMB file shares, Hadoop clusters, self-managed or cloud object storage, AWS Snowcone, Amazon S3, Amazon EFS, and Amazon FSx, you can use AWS DataSync. DataSync is ideal for customers who need online migrations for active data sets, timely transfers for continuously generated data, or replication for business continuity.
Comment: the questions says combinations of two steps, so AB makes more sense
Comment: AWS DataSync does not support SFTP
Comment: The most appropriate combination of steps to automate the task of migrating the on-premises SFTP server to an Amazon EC2 instance using Amazon EFS is: A. Launch the EC2 instance into the same Availability Zone as the EFS file system. E. Use AWS DataSync to create a suitable location configuration for the on-premises SFTP server. Explanation: A. Launching the EC2 instance into the same Availability Zone as the EFS file system ensures optimal performance and low-latency access to the file system. E. AWS DataSync can be used to automate and accelerate the transfer of data between on-premises systems and AWS. Creating a suitable location configuration for the on-premises SFTP server with AWS DataSync facilitates the migration process. Therefore, options A and E together provide an efficient and automated approach to migrate the data.
Comment: My choice is B and E. Data Sync is used to transfer data between on-premises and AWS. It is required to deploy AWS Data Sync Agent in on-premises and configure the location FROM/TO in AWS Data Sync.
Comment: Apparently it's not B, as it says: "Install" an AWS DataSync agent in the on-premises data center. You actually don't install it. You deploy it as a vm or EC2. So I guess it's the terminology that hints at "E"
Comment: This is the purpose of bookmarks: "AWS Glue tracks data that has already been processed during a previous run of an ETL job by persisting state information from the job run. This persisted state information is called a job bookmark. Job bookmarks help AWS Glue maintain state information and prevent the reprocessing of old data." https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html
Comment: A. Job bookmarks in Glue allow you to track the last-processed data in a job. By enabling job bookmarks, Glue keeps track of the processed data and automatically resumes processing from where it left off in subsequent job runs. B. Results in the permanent removal of the data from the S3, making it unavailable for future job runs. This is not desirable if the data needs to be retained or used for subsequent analysis. C.It would only affect the parallelism of the job but would not address the issue of reprocessing old data. It does not provide a mechanism to track the processed data or skip already processed data. D. It is not directly related to preventing Glue from reprocessing old data. The FindMatches transform is used for identifying and matching duplicate or matching records in a dataset. While it can be used in data processing pipelines, it does not address the specific requirement of avoiding reprocessing old data in this scenario.
Comment: B: Glue can delete DataSet but this option is too vague to consider or too open to mean anything C: Won't help with repeated ETL. This property affects parallelism D: Too vague
Comment: https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html
Comment: The best solution is to edit the AWS Glue job to use job bookmarks. Job bookmarks allow AWS Glue ETL jobs to track which data has already been processed during previous runs. This prevents reprocessing of old data. Deleting the data after processing would cause the data to be lost and unavailable for future processing. Reducing the number of workers may improve performance but does not prevent reprocessing of old data. Using a FindMatches ML transform is used for record matching, not preventing reprocessing. So the solutions architect should enable job bookmarks in the AWS Glue job configuration. This will allow the ETL job to keep track of processed data and only transform the new data added since the last run.
Comment: Job bookmark to make sure that the glue job will not process already processed files.
Comment: Job bookmarks are used in AWS Glue ETL jobs to keep track of the data that has already been processed in a previous job run. With bookmarks enabled, AWS Glue will read the bookmark information from the previous job run and will only process the new data that has been added to the data source since the last job run. This saves time and reduces costs by eliminating the need to reprocess old data. Therefore, a solutions architect should edit the AWS Glue ETL job to use job bookmarks so that it will only process new data added to the S3 bucket since the last job run.
Comment: Job bookmarks enable AWS Glue to track the data that has been processed in a previous run of the job. With job bookmarks enabled, AWS Glue will only process new data that has been added to the S3 bucket since the previous run of the job, rather than reprocessing all data every time the job runs.
Comment: Delete files in S3 freely is not good. so B is not correct,
Comment: A is correct
Comment: Option A. Edit the job to use job bookmarks. Job bookmarks in AWS Glue allow the ETL job to track the data that has been processed and to skip data that has already been processed. This can prevent AWS Glue from reprocessing old data and can improve the performance of the ETL job by only processing new data. To use job bookmarks, the solutions architect can edit the job and set the "Use job bookmark" option to "True". The ETL job will then use the job bookmark to track the data that has been processed and skip data that has already been processed in subsequent runs.
Comment: Option A
Comment: It's obviously A. Bookmarks serve this purpose
Comment: A is correct
Comment: A https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html
Comment: I think it is AC, reason is they require a solution that is highly available. AWS Shield can handle the DDoS attacks. To make the solution HA you can use cloud front. AC seems to be the best answer imo. AB seem like redundant answers. How do those answers make the solution HA?
Comment: A - AWS Shield Advanced C - (protecting this option) IMO: AWS Shield Advanced has to be attached. But it can not be attached directly to EC2 instances. According to the docs: https://aws.amazon.com/shield/ It requires to be attached to services such as CloudFront, Route 53, Global Accelerator, ELB or (in the most direct way using) Elastic IP (attached to the EC2 instance)
Comment: Option A. Use AWS Shield Advanced to stop the DDoS attack. It provides always-on protection for Amazon EC2 instances, Elastic Load Balancers, and Amazon Route 53 resources. By using AWS Shield Advanced, the solutions architect can help protect the website from large-scale DDoS attacks. Option C. Configure the website to use Amazon CloudFront for both static and dynamic content. CloudFront is a content delivery network (CDN) that integrates with other Amazon Web Services products, such as Amazon S3 and Amazon EC2, to deliver content to users with low latency and high data transfer speeds. By using CloudFront, the solutions architect can distribute the website's content across multiple edge locations, which can help absorb the impact of a DDoS attack and reduce the risk of downtime for the website.
Comment: Note great options for us to select but AC seem make more sense comparing to others
Comment: CoPilot - "No, you do not need Amazon CloudFront to implement AWS Shield Advanced. AWS Shield Advanced provides protection for several AWS services, including Amazon EC2, Elastic Load Balancing (ELB), AWS Global Accelerator, and Amazon Route 53 resources, in addition to CloudFront distributions1. It's designed to offer more sophisticated protection against Distributed Denial of Service (DDoS) attacks, regardless of the AWS service being used1. However, it's important to note that while CloudFront is not a requirement, using AWS Shield Advanced with CloudFront can enhance your application's security by providing additional DDoS protection."
Comment: A and C is the most logical combination, we implement cloudfront so we can use shield advanced. Both of these options mitigate the impact of a DDOS attack.
Comment: AC is more close to meet the requirenment
Comment: A: For DDoS attakcs C: For scalable available site B: Irrelevant D: How would Lambda identify the attacker IP even if this was possible (ACL has a limit of 40 rules each way) E: Scaling is not an issue here
Comment: A - use aws shield advanced for DDoS protection, but it cannot be used with EC2 instace if it's not using EIP, which is not mentioned C - but it can be used with cloudfront distribution thus AC is the answer
Comment: DDoS attack will choose the AWS Shield Advanced Cloudfront have attached the WAF
Comment: A - no brainer E = "must design a highly available infrastructure". I am not sure if CloudFront addresses this requirement.
Comment: Is CloudFront not HA? Answer E uses Spot instances which might be unavailable, thus are NEVER an option for HA.
Comment: You are right if it was On demand instances we could think of E
Comment: pentium75 is right.
Comment: Mitigate a large-scale DDoS attack = AWS Shield Advanced Downtime is not acceptable for the website = high availability = Amazon CloudFront
Comment: yeah , AWS Shield Advanced can be used directly on EC2..... https://docs.aws.amazon.com/waf/latest/developerguide/ddos-protections-by-resource-type.html
Comment: Why D then?
Comment: Cloud front supports SHIELD ADVANCED integration
Comment: Cloud front supports SHIELD ADVANCED integration
Comment: D should be the one here
Comment: "Use an AWS Lambda function to automatically add attacker IP addresses to VPC network ACLs"?????
Comment: A. AWS Shield Advanced provides advanced DDoS protection for AWS resources, including EC2. It includes features such as real-time threat intelligence, automatic protection, and DDoS cost protection. C. CloudFront is a CDN service that can help mitigate DDoS attacks. By routing traffic through CloudFront, requests to the website are distributed across multiple edge locations, which can absorb and mitigate DDoS attacks more effectively. CloudFront also provides additional DDoS protection features, such as rate limiting, SSL/TLS termination, and custom security policies. B. While GuardDuty can detect and provide insights into potential malicious activity, it is not specifically designed for DDoS mitigation. D. Network ACLs are not designed to handle high-volume traffic or DDoS attacks efficiently. E. Spot Instances are a cost optimization strategy and may not provide the necessary availability and protection against DDoS attacks compared to using dedicated instances with DDoS protection mechanisms like Shield Advanced and CloudFront.
Comment: Key word: DDoS attack will choose the AWS Shield Advanced Cloudfront have attached the WAF
Comment: Best way to check it... The question is taken from the example shown here in the documentation: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html#eb-lambda-permissions
Comment: The correct solution is D. Add a resource-based policy to the function with lambda:InvokeFunction as the action and Service: events.amazonaws.com as the principal. The principle of least privilege requires that permissions are granted only to the minimum necessary to perform a task. In this case, the Lambda function needs to be able to be invoked by Amazon EventBridge (Amazon CloudWatch Events). To meet these requirements, you can add a resource-based policy to the function that allows the InvokeFunction action to be performed by the Service: events.amazonaws.com principal. This will allow Amazon EventBridge to invoke the function, but will not grant any additional permissions to the function.
Comment: Why other options are wrong Option A is incorrect because it grants the lambda:InvokeFunction action to any principal (*), which would allow any entity to invoke the function and goes beyond the minimum permissions needed. Option B is incorrect because it grants the lambda:InvokeFunction action to the Service: lambda.amazonaws.com principal, which would allow any Lambda function to invoke the function and goes beyond the minimum permissions needed. Option C is incorrect because it grants the lambda:* action to the Service: events.amazonaws.com principal, which would allow Amazon EventBridge to perform any action on the function and goes beyond the minimum permissions needed.
Comment: Following the principle of least privilege, you should not grant Events the * privilege. Just enough to perform its job will do. Also, you need a resource-based policy to attach to the function, for Events to be able to execute the function
Comment: D is the correct answer
Comment: This is a good example article with nice learning material. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-run-lambda-schedule.html
Comment: Good explanation from ChatGPT: In order to adhere to the principle of least privilege when configuring permissions for an AWS Lambda function invoked by an Amazon EventBridge (CloudWatch Events) rule, the most appropriate solution would be: D. Add a resource-based policy to the function with lambda:InvokeFunction as the action and Service: events.amazonaws.com as the principal. This solution involves attaching a resource-based policy to the Lambda function. It specifies that the only entity allowed to invoke the Lambda function is the Amazon EventBridge service (represented by the principal events.amazonaws.com) and restricts the action to only invoking the function (lambda:InvokeFunction). This aligns with the principle of least privilege by granting the necessary permissions explicitly to the service that needs them, without providing overly permissive access.
Comment: Is anyone can explain why B is can't be a good choice? The option adds the execution role to the function, with lambda:InvokeFunction as the action and Service: lambda.amazonaws.com as the body. This restricts the Lambda function to only the Lambda service, providing an effective layer of security. and fully complies with the principle of least privilege
Comment: Because the question is about the permission 'to run the function' (permission for the administrator to invoke it), while B is about execution permissions (permission for the function to access resources).
Comment: why not choose B, an execution role is attached to lambda and a policy is attached to an execution role
Comment: B would be the wrong choice as the both roles are granted to lambda, however the question requires Eventbridge to call the Lambda function.
Comment: lambda:InvokeFunction is the action needed to invoke the Lambda function. Service: events.amazonaws.com is the principal (the AWS service) that is allowed to invoke the Lambda function. In this case, you're explicitly allowing CloudWatch Events to invoke the function.
Comment: D * is BIG NO. And we are talking about policy --> hence D
Comment: In this solution, a resource-based policy is added to the Lambda function, which allows the specified principal (events.amazonaws.com) to invoke the function. The lambda:InvokeFunction action provides the necessary permission for the Amazon EventBridge rule to trigger the Lambda function. Option A is incorrect because it assigns the lambda:InvokeFunction action to all principals (*), which grants permission to invoke the function to any entity, which is broader than necessary. Option B is incorrect because it assigns the lambda:InvokeFunction action to the specific principal "lambda.amazonaws.com," which is the service principal for AWS Lambda. However, the requirement is for the EventBridge service principal to invoke the function. Option C is incorrect because it assigns the lambda:* action to the specific principal "events.amazonaws.com," which is the service principal for Amazon EventBridge. However, it grants broader permissions than necessary, allowing any Lambda function action, not just lambda:InvokeFunction.
Comment: Option C is incorrect, the reason is that, firstly, lambda:* allows Amazon EventBridge to perform any action on the function and this is beyond the minimum permissions needed.
Comment: Since its for Lamda which is a resource, resource policy is the trick
Comment: https://docs.aws.amazon.com/eventbridge/latest/userguide/resource-based-policies-eventbridge.html#lambda-permissions
Comment: The definition scope of D is the smallest, so is it
Comment: events.amazonaws.com is principal for eventbridge
Comment: Option D
Comment: The MOST operationally efficient one is D. Automating the key rotation is the most efficient. Just to confirm, the A and B options don't allow automate the rotation as explained here: https://aws.amazon.com/kms/faqs/#:~:text=You%20can%20choose%20to%20have%20AWS%20KMS%20automatically%20rotate%20KMS,KMS%20custom%20key%20store%20feature
Comment: In addition you cannot log key usage in B, for A I am not certain
Comment: Thank you for the explanation.
Comment: SSE-KMS provides a secure and efficient way to encrypt data at rest in S3. SSE-KMS uses KMS to manage the encryption keys securely. With SSE-KMS, encryption keys can be automatically rotated using KMS key rotation feature, which simplifies the key management process and ensures compliance with the requirement to rotate keys every year. Additionally, SSE-KMS provides built-in audit logging for encryption key usage through CloudTrail, which captures API calls related to the management and usage of KMS keys. This meets the requirement for logging key usage for auditing purposes. Option A (SSE-C) requires customers to provide their own encryption keys, but it does not provide key rotation or built-in logging of key usage. Option B (SSE-S3) uses Amazon S3 managed keys for encryption, which simplifies key management but does not provide key rotation or detailed key usage logging. Option C (SSE-KMS with manual rotation) uses AWS KMS keys but requires manual rotation, which is less operationally efficient than the automatic key rotation available with option D.
Comment: Ans D - just the Amazon provided service with key automatic key rotation
Comment: Correct Answer: D Automatic Key Rotation = KMS, hence Option A & B are not correct answer. Hence Possible answer is Option C or D. Now mentioned in the requirement that key rotation solution must be automated. So Option C is not the correct answer. Correct Answer: D - SSE with KMS which support automatic key rotation.
Comment: I got this question in exam today (FEB 21, 2024)
Comment: I'll go for D as SSS-S3 has unpublished scheduled of rotation which may or may not be "each year". https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html
Comment: SSE-S3 can be used for logging in cloudtrail since January 5, 2023 https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html
Comment: But "keys must be rotated every year". I understand that SSE-S3 rotates the keys "regularly" but you have no influence on the schedule.
Comment: The correct answer is D. Server-side encryption with AWS KMS keys (SSE-KMS) with automatic rotation. SSE-KMS is the most secure way to encrypt data in Amazon S3. It uses AWS KMS, which is a highly secure key management service that is managed by AWS. AWS KMS logs all key usage, so the company can meet its compliance requirements. AWS KMS also rotates keys automatically, so the company does not have to worry about manually rotating keys.
Comment: Server-side encryption with AWS KMS keys (SSE-KMS) with automatic rotation meets the requirements and is the most operationally efficient solution. This option allows you to use AWS KMS to automatically rotate the keys every year, which simplifies key management. In addition, key usage is logged for auditing purposes, and the data is encrypted at rest to meet compliance requirements.
Comment: mazon API Gateway is a fully managed service that makes it easy to create, publish, maintain, monitor, and secure APIs at any scale. You can use API Gateway to create a REST API that exposes the location data as an API endpoint, allowing you to access the data from your analytics platform. AWS Lambda is a serverless compute service that lets you run code in response to events or HTTP requests. You can use Lambda to write the code that retrieves the location data from your data store and returns it to API Gateway as a response to API requests. This allows you to scale the API to handle a large number of requests without the need to provision or manage any infrastructure.
Comment: This question is about server-side encryption, not API Gateway
Comment: The most operationally efficient solution that meets the requirements listed would be option D: Server-side encryption with AWS KMS keys (SSE-KMS) with automatic rotation. SSE-KMS allows you to use keys that are managed by the AWS Key Management Service (KMS) to encrypt your data at rest. KMS is a fully managed service that makes it easy to create and control the encryption keys used to encrypt your data. With automatic key rotation enabled, KMS will automatically create a new key for you on a regular basis, typically every year, and use it to encrypt your data. This simplifies the key rotation process and reduces the operational burden on your team. In addition, SSE-KMS provides logging of key usage through AWS CloudTrail, which can be used for auditing purposes.
Comment: Why other options are wrong Option A: Server-side encryption with customer-provided keys (SSE-C) would require you to manage the encryption keys yourself, which can be more operationally burdensome. Option B: Server-side encryption with Amazon S3 managed keys (SSE-S3) does not allow for key rotation or logging of the key usage. Option C: Server-side encryption with AWS KMS keys (SSE-KMS) with manual rotation would require you to manually initiate the key rotation process, which can be more operationally burdensome compared to automatic rotation.
Comment: Option D
Comment: You can choose to have AWS KMS automatically rotate KMS keys every year, provided that those keys were generated within AWS KMS HSMs. Automatic key rotation is not supported for imported keys, asymmetric keys, or keys generated in a CloudHSM cluster using the AWS KMS custom key store feature. If you choose to import keys to AWS KMS or asymmetric keys or use a custom key store, you can manually rotate them by creating a new KMS key and mapping an existing key alias from the old KMS key to the new KMS key.
Comment: Can anybody correct me if I'm wrong, KMS does not offer automatic rotations but SSE-KMS only allows automatic rotation once in 3 years thus if we want rotation every year we need to rotate it manually?
Comment: You're wrong :) "All AWS managed keys are automatically rotated every year. You cannot change this rotation schedule." https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk
Comment: Agree Also, SSE-S3 cannot be audited.
Comment: API Gateway is needed to get the data so option A and C are out. “The company wants to use these data points in its existing analytics platform” so there is no need to add Kynesis. Option D is also out. This leaves us with option B as the correct one.
Comment: While API Gateway and Lambda can work together for processing requests, this setup doesn't efficiently handle continuous real-time data streaming and analysis, which is required for tracking the bicycle locations. Lambda is stateless and is better suited for on-demand execution, not for real-time analytics of streaming data. So, the correct option is D
Comment: AWS Lambda is a serverless compute service that can be used to run code in response to specific events, such as changes to data in an Amazon S3 bucket or updates to a DynamoDB table. It could be used to process the location data, but it doesn't provide storage solution. Therefore, it would not be the best option for storing and retrieving location data in this scenario.
Comment: You are right, but it clearly say "store data". AWS Lambda don't store data, Kinesis could.
Comment: i dont understand the use of a lambda function here, maybe if there would be need to transform the data, can you explain?
Comment: I dont understand why you will vote B? how are you going to store data with just lambda? > Which action meets these requirements for storing and retrieving location data In this use case there will obviously be a ton of data and you want to get real-time location data of the bicycles, and to analyze all these info kinesis is the one that makes most sense here.
Comment: Lambda isn't storing the data themselves. It's triggering the data store to the company's "existing data analytics platform"
Comment: Real-time analytics on Kinesis Data Streams & Firehose using SQL, not store db ...
Comment: https://aws.amazon.com/blogs/aws/real-time-hotspot-detection-in-amazon-kinesis-analytics/
Comment: I don't think you need to worry about storing data. The question states their is an existing platform.
Comment: it should be D because ChatGPT said that :D
Comment: The most viable option for storing and retrieving location data in a multi-tier architecture with the requirements mentioned is D. Use Amazon API Gateway with Amazon Kinesis Data Analytics. Here's why: Amazon API Gateway: It provides a managed solution for exposing a REST API, which is needed for making the location data accessible to external clients and applications. Amazon Kinesis Data Analytics: This service is designed to handle real-time data streams and analytics, which is ideal for tracking the location of bicycles during peak operating hours when real-time data processing is essential. Kinesis Data Analytics can efficiently process, analyze, and store the location data from bicycles, making it a good fit for real-time tracking scenarios. This solution supports the real-time ingestion of location data and enables integration with the company's existing analytics platform for further processing, while also providing access to the data via REST APIs.
Comment: continues here... Why the other options are less viable: A. Use Amazon Athena with Amazon S3: While Athena is great for querying large datasets stored in S3, it is not suitable for real-time data processing and tracking since it is more focused on batch querying rather than continuously ingesting and processing live data streams. B. Use Amazon API Gateway with AWS Lambda: While this combination is useful for building scalable APIs, AWS Lambda is not designed for high-throughput real-time data processing or storage of continuous data streams. It would be complex and inefficient for storing and analyzing real-time location data from the bikes. C. Use Amazon QuickSight with Amazon Redshift: QuickSight is primarily a data visualization tool, and Redshift is used for data warehousing and batch processing. This combination is not suitable for handling real-time streaming data and making it accessible via a REST API.
Comment: Ans D - hint: "The data points must be accessible from the REST API" so we need an API interface - that's leaves only B or D, of which B uses a Lambda function (undefined) and D provides Kinesis data analytics
Comment: Kinesis data analytics cant consume from API Gateway, only from Kinesis Data Stream or Amazon Data Firehose https://docs.aws.amazon.com/es_es/kinesisanalytics/latest/dev/what-is.html
Comment: B seems right, because it has already existing analytics plateform so don't need D.
Comment: In option B who will ingest realtime data in S3 ? so Answer is D.
Comment: RDS Event Notification: Amazon RDS supports event notifications, which can trigger actions when specific events occur, such as a record update or delete operation. In this case, an event would be triggered when a listing is removed. Amazon SNS: SNS allows the event to be published to a topic that can then be fanned out to multiple SQS queues. This is useful when you have multiple target systems that need to receive the data. SNS can push the message to all subscribed SQS queues simultaneously. Amazon SQS: SQS provides reliable message queuing. Each target system can consume messages from its respective SQS queue at its own pace, ensuring that no messages are lost. AWS Lambda: Lambda functions can be triggered by the SQS queues to process the messages and update the target systems accordingly. This approach allows for asynchronous processing and decouples the RDS update from the target system updates, improving scalability and reliability.
Comment: D is the correct answer!
Comment: To meet the requirements for storing and retrieving location data in a multi-tier architecture with accessibility from a REST API, the most viable option would be to use Amazon API Gateway with AWS Lambda. This combination allows for the creation of a serverless architecture that can handle the data points effectively: Amazon API Gateway: Acts as the front door for the REST API, managing and securing the traffic to the back-end services. AWS Lambda: Processes the incoming requests from the API Gateway, performs operations such as storing and retrieving location data, and integrates with other AWS services as needed. This setup enables the bicycle sharing company to have a scalable, cost-effective, and efficient system for tracking the location of its bicycles and integrating the data with its existing analytics platform.
Comment: All of these options are a little bit vague, we can rule out A and C because they don't provide a solution for the API requirement, since the company has it's own analytics platform, we can rule out D, although option B doesn't provide a storage solution, it's the one that makes the most sense.
Comment: Option A makes more sense as this provide both storing option as S3 and rest endpoint in Athena to retrieve data points integrating with S3
Comment: B for sure
Comment: you can't store data in lambda
Comment: Track location, it should be streaming
Comment: D is more reasonable than B
Comment: https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html
Comment: Interesting point that Amazon RDS event notification doesn't support any notification when data inside DB is updated. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html So subscription to RDS events doesn't give any value for Fanout = SNS => SQS B is out because FIFO is not required here. A is left as correct answer
Comment: Option A suggests creating an AWS Lambda function triggered when the database on Amazon RDS is updated to send the information to an Amazon Simple Queue Service (Amazon SQS) queue for the targets to consume. While this approach can work, it has a few limitations compared to Option D: Scalability and Fan-out: Option A uses a single SQS queue, which means all target systems would need to poll the same queue. This can become a bottleneck if multiple systems need to process the data simultaneously. Option D, on the other hand, uses an SNS topic to fan out the event to multiple SQS queues, allowing each target system to have its own queue. This improves scalability and ensures that each target system can process the data independently. Option D offers a more scalable, decoupled, and flexible solution for handling the event notifications and distributing the data to multiple target systems.
Comment: But... SQS is a queue and is incapable of sending messages to "multiple target systems". SNS is pub/sub and topics can be subscribed by multiple apps to update when such an even occurs. Moreover Amazon RDS uses native capabilities of DBs like Postgres, MS SQL for change data capture. This can be used to send notifications to SNS
Comment: Listing the Amazon RDS event notification categories. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.ListingCategories.html:
Comment: D is connect RDS event notification by RDS stream or advance audit DML so it is possible
Comment: The key is "Fanned out" due to "Multiple target systems" need to update
Comment: Please provide reference for this claim: " event notification by RDS stream or advance audit DML"
Comment: RDS events only provide operational events such as DB instance events, DB parameter group events, DB security group events, and DB snapshot events. What we need in the scenario is to capture data-modifying events (INSERT, DELETE, UPDATE) which can be achieved thru native functions or stored procedures.
Comment: I agree with it requiring a native function or stored procedure, but can they in turn invoke a Lambda function? I have only seen this being possible with Aurora, but not RDS - and I'm not able to find anything googling for it either. I guess it has to be possible, since there's no other option that fits either. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html
Comment: To add to that though, A also states to only use SQS (no SNS to SQS fan-out), which doesn't seem right as the message needs to go to multiple targets?
Comment: A for sure
Comment: You have to fan out first with SNS
Comment: The best design is **D. Subscribe to an RDS event notification and send an Amazon SNS topic fanned out to multiple Amazon SQS queues. Use AWS Lambda functions to update the targets**. - **SNS fan-out** enables sending data to multiple SQS queues for different target systems. - **Lambda** can process messages from each SQS queue and update the targets. ### Why not others: - **A** and **B**: No fan-out mechanism, making it harder to deliver to multiple targets. - **C**: Reverses the typical fan-out pattern (SQS to SNS) and is less efficient. Option D offers better scalability and decoupling.
Comment: A and C cannot be correct: "an (one) SQS queue for the targets (multiple) to consume". "an (one) SQS queue fanned out to multiple SNS" That would be one-to-many relationship, which is not supported by SQS. "SQS has a many-to-one relationship. You can send messages to a queue from many different producers but only one consumer can be defined." https://blog.awsfundamentals.com/aws-sns-vs-sqs-what-are-the-main-differences#heading-many-to-many-vs-many-to-one-number-of-consumers
Comment: Answer is D, this is a typical scenario for SQS fan-out. A can not send data to multiple targets
Comment: Ans C - using SQS means events are time-order preserved and then can be sent to multiple consumers using SNS
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: RDS Event Notification: Amazon RDS supports event notifications, which can trigger actions when specific events occur, such as a record update or delete operation. In this case, an event would be triggered when a listing is removed. Amazon SNS: SNS allows the event to be published to a topic that can then be fanned out to multiple SQS queues. This is useful when you have multiple target systems that need to receive the data. SNS can push the message to all subscribed SQS queues simultaneously. Amazon SQS: SQS provides reliable message queuing. Each target system can consume messages from its respective SQS queue at its own pace, ensuring that no messages are lost. AWS Lambda: Lambda functions can be triggered by the SQS queues to process the messages and update the target systems accordingly. This approach allows for asynchronous processing and decouples the RDS update from the target system updates, improving scalability and reliability.
Comment: Fan out needs SNS
Comment: Why not answer (B) because the car sold first should be updated on the target system first so that more than one customers cannot purchase the same car
Comment: Fan-out pattern chose D
Comment: I can't understand why people are opting for A but not B. Using a standard SQS queue (non-FIFO) does not guarantee message order and can lead to potential duplicate processing if not handled carefully. This might not be suitable when precise order and exactly-once processing are required, as in the case of removing automobile listings and sending data to multiple systems simultaneously.
Comment: Rule of thumb: don't assume requirements and don't overthink what is being asked. While everything you said might be true, the question doesn't mention any concerns about duplication or ordering.
Comment: confuse with A and D as both violate one of the another. But Options D looks more appropriate to fan out to multiple targets using SNS
Comment: I am not sure why the folks who selected A don't select B instead. Given that this is basically e-commerce, you would want the action to be processed "exactly once" (i.e. you can only sold a car once). In that case, FIFO will give "exactly once" behavior over standard, so you don't accidentally carry out an action multiple times for the same sale.
Comment: Exactly
Comment: D could have been a perfect solution but RDS does not create event notifications based on database updates .. You can refer to the link below to the kind of events RDS triggers notifications for => https://dzone.com/articles/how-can-i-know-what-happens-inside-amazon-rds#:~:text=an%20event%20subscription.-,AWS%20RDS%20Event%20Categories%20and%20Messages,-Amazon%20RDS%20generates A is a good alternative that lacks fanning out which will not be necessary if the visibility timeout is adjusted properly and the targets are not many. A is the near best alternative so I GO in for A.
Comment: To meet the requirements of reducing coupling within the application and improving website performance, the solutions architect should consider taking the following actions: C. Configure the application to upload images directly from each user's browser to Amazon S3 through the use of a pre-signed URL. This will allow the application to upload images directly to S3 without having to go through the web server, which can reduce the load on the web server and improve performance. D. Configure S3 Event Notifications to invoke an AWS Lambda function when an image is uploaded. Use the function to resize the image. This will allow the application to resize images asynchronously, rather than having to do it synchronously during the upload request, which can improve performance.
Comment: presigned URL is for download the data from S3, not for uploads, so the user does not upload anything. C is no correct.
Comment: A user who does not have AWS credentials to upload a file can use a presigned URL to perform the upload. https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html
Comment: Presigned URL can be use for upload.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html
Comment: preassigned URL is for upload or download for temporary time and for specific users outside the company
Comment: but for temporary purpose not for permanent
Comment: So? You only need a presigned URL for the moment you upload the image, not forever
Comment: that's right
Comment: Why other options are wrong Option A, Configuring the application to upload images to S3 Glacier, is not relevant to improving the performance of image uploads. Option B, Configuring the webserver to upload the original images to Amazon S3, is not a recommended solution as it would not reduce coupling within the application or improve performance. Option E, Creating an Amazon EventBridge (Amazon CloudWatch Events) rule that invokes an AWS Lambda function on a schedule to resize uploaded images, is not a recommended solution as it would not be able to resize images in a timely manner and would not improve performance.
Comment: About your comments regarding option B)... But if images are being saved directly to S3 instead of the EBS/SSD storage of E2 instances as they originally were, the new approach will reduce coupling and improve performance. Also you have to consider the security concerns about presign URLs as the question does not mention if users are public or private.
Comment: Here it means to decouple the processes, so that the web server don't have to do the resizing, so it doesn't slow down. The customers access the web server, so the web server have to be involved in the process, and how the others already wrote, the pre-signed URL is not the right solution because, of the explanation you can read in the other comments. And additional! "Configure the application to upload images directly from EACH USER'S BROWSER to Amazon S3 through the use of a pre-signed URL" I am not an expert, but I can't imagine that you can store an image that an user uploads in his browser etc.
Comment: Why would anyone vote C? signed URL is for temporary access. also, look at the vote here: https://www.examtopics.com/discussions/amazon/view/82971-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: I agree with you. C seems a temporary solution if a download or upload demend is urgent.
Comment: It's very clear C D
Comment: I'm sorry it's B D
Comment: C, D for sure
Comment: Ans B, D - 1st: Upload the original images to Amazon S3 2nd: Configure S3 Event Notifications to invoke an AWS Lambda function when an image is uploaded to resize the image.
Comment: I am voting for C and D. B and D could also work, but when you upload the images to the EC2 and then to S3 it could cause additional performance and network traffic load.
Comment: I don't understand why the expiration time of presigned urls is being questioned. You can certainly design an upload flow that uses the SDK to create a new presigned url before uploading.
Comment: B and D is the way to go
Comment: CD - No point having the instance do extra work when we can use pre signed URLs and let the user directly upload to S3, hence B is not an operationally efficient option. Furthermore B results in more traffic through the instance which is inefficient.
Comment: C is not a valid option to upload the image is to have presigned url to retrieve the file/image from S3
Comment: BD is more reasonable than CD
Comment: BD is the answer, idk why anyone would choose c ?? pre-signed urls are for security pursoses
Comment: GPT4 option B would offload the storage to S3 but still involves the web server in the upload process, which does not fully address the performance issues.
Comment: GPT4 is wrong. It does address the performance issue with the image processing will be done by lambda and not on the server
Comment: GPT4 option B would offload the storage to S3 but still involves the web server in the upload process, which does not fully address the performance issues.
Comment: C: presigned URL can be used to upload images to S3 https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html D: scalable event processing for image resizing using lambda A: Glacier? B: Can work and maybe improves the performance also as the webserver is not resizing the image (if D is used in combination with this). However, C is better E: Irrelevant
Comment: B could be excluded because of these two points: - During upload requests, the website resizes the images to a standard size and stores the resized images in Amazon S3. - Users are experiencing slow upload requests to the website.
Comment: C is out of question as URL is not generated by user and highest validity is 7 days. So if user needs to access same file after 7 days it would be very troublesome.
Comment: How is S3 glacier going to help with uploads?
Comment: Answer is D as the "HIGHEST available" and less "operational complex" The "Amazon RDS for MySQL with Multi-AZ enabled" option excludes A and B The "Auto Scaling group" is more available and reduces operational complexity in case of incidents (as remediation it is automated) than just adding one more instance. This excludes C. C and D to choose from based on D over C since is configured
Comment: Ans D - extends the architecture rather than complicating it: Amazon MQ with active/standby brokers configured across two Availability Zones; Auto Scaling group for the consumer EC2 instances across two Availability Zones; Amazon RDS for MySQL with Multi-AZ enabled.
Comment: - Active MQ with active/standby - Auto scaling across 2 AZs - RDS with Multi AZ. These provide the highest availability and least complexity (using Amazon MQ, auto scaling and RDS, all managed services)
Comment: D is obviously the highest available.
Comment: Definitely it's D
Comment: D: Managed and auto-scaling, resilient and HA service for each tier. This is well-architected too.
Comment: Using Amazon MQ with active/standby brokers provides highly available message queuing across AZs. Adding an Auto Scaling group for consumer EC2 instances across 2 AZs provides highly available processing. Using RDS MySQL with Multi-AZ provides a highly available database. This architecture provides high availability for all components of the system - queue, processing, and database.
Comment: Ans is C - C. Option C uses Amazon MQ with active/standby brokers, adds an additional consumer EC2 instance, and uses Amazon RDS for MySQL with Multi-AZ enabled. Amazon RDS Multi-AZ automatically replicates your database to another AZ and provides automated failover. This ensures high availability for both the messaging system and the database. Option D- bring More scalabilty rather HA
Comment: D automates replacement of failed instances, thus it has higher availability than C.
Comment: HIGHEST availability. Definitely option D.
Comment: The key reasons are: Amazon MQ active/standby brokers across AZs for queue high availability Auto Scaling group with consumer EC2 instances across AZs for redundant processing RDS MySQL with Multi-AZ for database high availability This combines the HA capabilities of MQ, EC2 and RDS to maximize fault tolerance across all components. The auto scaling also provides flexibility to scale processing capacity as needed.
Comment: D is the correct answer. Using Amazon MQ with active/standby brokers provides highly available message queuing across AZs. Adding an Auto Scaling group for consumer EC2 instances across 2 AZs provides highly available processing. Using RDS MySQL with Multi-AZ provides a highly available database. This architecture provides high availability for all components of the system - queue, processing, and database.
Comment: Keyword Amazon RDS, has C and D. Then D has "Auto Scaling group", choose D.
Comment: D With 3 options with Amazon MQ --> A is odd one out / Then ASG with M-AZ was an easy choice
Comment: Amazon MQ with active/standby brokers configured across two AZ ensures high availability for the message broker. In case of a failure in one AZ, the other AZ's broker can take over seamlessly. Adding an ASG for the consumer EC2 instances across two AZ provides redundancy and automatic scaling based on demand. If one consumer instance becomes unavailable or if the message load increases, the ASG can automatically launch additional instances to handle the workload. Using RDS for MySQL with Multi-AZ enabled ensures high availability for the database. Multi-AZ automatically replicates the database to a standby instance in another AZ. If a failure occurs, RDS automatically fails over to the standby instance without manual intervention. This architecture combines high availability for the message broker (Amazon MQ), scalability and redundancy for the consumer EC2 instances (ASG), and high availability for the database (RDS Multi-AZ). It offers the highest availability with low operational complexity by leveraging managed services and automated failover mechanisms.
Comment: Correct answer D
Comment: to achieve ha + low operational complexity, the solution architect has to choose option D, which fulfill these requirements.
Comment: Auto scaling and Multi-AZ enabled for high availability.
Comment: Less operational overhead means A: Fargate (no EC2), move the containers on ECS, autoscaling for growth and ALB to balance consumption. B - requires configure EC2 C - requires add code (developpers) D - seems like the most complex approach, like re-architecting the app to take advantage of an HPC platform.
Comment: And A - its containers so use FarGate, add some auto-scaling...
Comment: A makes sense
Comment: key = LEAST operational overhead Fargate a serverless service fully managed by aws https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html#:~:text=AWS%20Fargate%20is,optimize%20cluster%20packing.
Comment: Less operational overhead means A: Fargate (no EC2), move the containers on ECS, autoscaling for growth and ALB to balance consumption.
Comment: LEAST operational overhead = AWS Fargate
Comment: A is the best solution to meet the requirements with the least operational overhead. The key reasons are: AWS Fargate removes the need to provision and manage servers. Fargate will automatically scale the application based on demand. This removes a significant operational burden. Using ECS along with Fargate provides a managed orchestration layer to easily run and scale the containerized application. The Application Load Balancer handles distribution of traffic without additional effort. No code changes are required to move the application to Fargate. The containers can run as-is.
Comment: A is the correct answer. AWS Fargate removes the need to provision and manage servers, allowing you to focus on deploying and running applications. Fargate will scale compute capacity up and down automatically based on application load. This removes the operational overhead of managing servers.
Comment: Existing: "containerized web-app", "minimum code changes + minimum development effort" --> AWS Fargate + Amazon Elastic Container Services (ECS). Easy question.
Comment: A Fargate, ECS, ASG, ALB….What else one will need for a nice sleep?
Comment: Option A (AWS Fargate on Amazon ECS with Service Auto Scaling) is the best choice as it provides a serverless and managed environment for your containerized web application. It requires minimal code changes, offers automatic scaling, and utilizes an Application Load Balancer for request distribution. Option B (Amazon EC2 instances with an Application Load Balancer) requires manual management of EC2 instances, resulting in more operational overhead compared to option A. Option C (AWS Lambda with API Gateway) may require significant code changes and restructuring, introducing complexity and potentially increasing development effort. Option D (AWS ParallelCluster) is not suitable for a containerized web application and involves significant setup and configuration overhead.
Comment: AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.
Comment: Least Operational Overhead = Serverless
Comment: AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers on clusters of Amazon EC2 instances. With Fargate, you no longer have to provision, configure, or scale of virtual machines to run containers. https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html
Comment: A is correct
Comment: The best solution to meet the requirements with the least operational overhead is Option A: Use AWS Fargate on Amazon Elastic Container Service (Amazon ECS) to run the containerized web application with Service Auto Scaling. Use an Application Load Balancer to distribute the incoming requests.
Comment: Option A has minimum operational overhead and almost no application code changes.
Comment: A. Use AWS DataSync to move the data. Create a custom transformation job by using AWS Glue. - No BW available for DataSync, so "asap" will be weeks/months (?) B. Order an AWS Snowcone device to move the data. Deploy the transformation application to the device. - Snowcone will just store 14TB (SSD configuration). **C**. Order an AWS Snowball Edge Storage Optimized device. Copy the data to the device. Create a custom transformation job by using AWS Glue. - SnowBall can store 80TB (ok), takes around 1 week to move the device (faster than A), and AWS Glue allows to do ETL jobs. This is the answer. D. Order an AWS Snowball Edge Storage Optimized device that includes Amazon EC2 compute. Copy the data to the device. Create a new EC2 instance on AWS to run the transformation application. - Same as C, but the ETL job requires the deployment/configuration/maintenance of an EC2 instance, while Glue is serverless. This means D has more operational overhead than C.
Comment: I agree. When it said "with least Operational overhead" , it does not takes in account "migration activities" neccesary to reach the "final photo/scenario". In "operational overhead" schema, you're situated in a "final scenario" and you've only take into account how do you operate it, and if the operation of that scheme is ALIGHTED (least effort to operate than original scenario), that's the desired state.
Comment: I disagree on D. transformation job is already in place.so, all you have to do is deploy and run on ec2. C takes more effort to build Glue process, like reinventing the wheel . this is unnecessary
Comment: the differene between snowball with ec2 and without ec2 is $200 (for us east 1). fair to assume aws glue will not be more than that
Comment: Why C? This answer misses the part between SnowBall and AWS Glue. D at least provides a full-step solution that copies data in snowball device, and installs the custom application in device's EC2 to do the transformation job.
Comment: AWS Glue is not part of SnowBall Edge AWS services it can run within. Check it out here : https://docs.aws.amazon.com/snowball/latest/developer-guide/whatisedge.html
Comment: Because AWS Glue means less "operational (!) overhead" than running an EC2 instance.
Comment: Ans D - but I suspect it should be Ans C because, as stated by 123jhlo (1yr 11mth ago), D is not serverless: "**C**. Order an AWS Snowball Edge Storage Optimized device. Copy the data to the device. Create a custom transformation job by using AWS Glue. - SnowBall can store 80TB (ok), takes around 1 week to move the device (faster than A), and AWS Glue allows to do ETL jobs." D. Order an AWS Snowball Edge Storage Optimized device that includes Amazon EC2 compute. Copy the data to the device. Create a new EC2 instance on AWS to run the transformation application. - Same as C, but the ETL job requires the deployment/configuration/maintenance of an EC2 instance, while Glue is serverless. This means D has more operational overhead than C."
Comment: A and D are wrong. D is the correct answer. Why not C: AWS Snowball Edge is a physical device designed for transferring large amounts of data to and from AWS. It includes some compute capabilities, such as running AWS Lambda functions, AWS IoT Greengrass, and EC2 instances, but it does not support AWS Glue. AWS Glue is a fully managed ETL (Extract, Transform, Load) service that runs within the AWS Cloud. It is designed to work with data stored in AWS services like Amazon S3, Amazon RDS, and Amazon Redshift, among others. AWS Glue is not available on edge devices like Snowball Edge.
Comment: just correction A and B are wrong and D is the correct answer.
Comment: gotta be C surely..... LEAST operational overhead. EC2 = operational overhead. AWS Glue = managed service with transformation capabilities.
Comment: The q states that the custom job must remain, so glue is out. Seems like D is the only option as DataSync needs bandwidth.
Comment: Using an EC2 instance instead of a managed service like AWS Glue will include more operational overhead for the organization.
Comment: C is right Answer!! Get Up-To-Date https://www.pinterest.com/pin/937522847419120352
Comment: The answer is D because of the following key points 1. A custom application in the company's data center runs a weekly data transformation job. Which means that the company already has an application that runs the transformation. 2. A solutions architect must transfer the data and must configure the transformation job to continue to run in the AWS Cloud. This shows that the only responsibility of the architect is to transfer the data and configure the existing application to run on the EC2 the architect is going to deploy.
Comment: A: Cannot be done because no bandwidth B: Snowcone is probably to small D: Doable by EC2 is overhead for transformation when Glue is an option C: Is correct as Snowball Edge Storage Optimised device is good for storage and Glue can transform once the data is available
Comment: C best suit for: ETL jobs with LEAST operational overhead. For my understanding, we need here to avoir operation or maintenance burden of the solution
Comment: we use snowball to copy 50 PB "The company plans to pause the application until the data transfer is complete " and least over head " hence C would be reinventing the weel
Comment: which is faster? - setup a glue cluster and adapt it to do the same analytical stuff as the original app - simpley run the same app in an EC2 instance?
Comment: How are we going to run the custom application using glue? that means more time to adapt the process instead of just running the app in ec2
Comment: Not A. AWS DataSync requires an internet connection & the question states no available bandwidth Not B. SnowCone only has a max of 14 TB with an SSD, and the data is 50 TB Not C. Snowball Edge doesn't support Glue Supported services: https://docs.aws.amazon.com/snowball/latest/developer-guide/whatisedge.html So the answer must be D, as Snowball Edge Storage Optimized does support EC2 & can store 80 TB for the version that support compute resources
Comment: Snowball Edge has storage and compute capabilities, can be used to support workload in offline locations. Technically option D will work but with the overhead of EC2, negating the requirement for LEAST ops.
Comment: which is faster? - setup a glue cluster and adapt it to do the same analytical stuff as the original app - simpley run the same app in an EC2 instance?
Comment: The Snowball Edge Storage Optimized device allows transferring a large amount of data without using network bandwidth. Once the data is copied to the Snowball, AWS Glue can be used to create a custom ETL job to transform the data, avoiding the need to reconfigure the existing on-premises application. This meets the requirements to transfer the data with minimal operational overhead and configure the data transformation job to run in AWS
Comment: Do not store images in databases ;)... correct answer should be C
Comment: Solution C offloads the photo processing to Lambda. Storing the photos in S3 ensures scalability and durability, while keeping the metadata in DynamoDB allows for efficient querying of the associated information. Option A does not provide an appropriate solution for storing the photos, as DynamoDB is not suitable for storing large binary data like images. Option B is more focused on real-time streaming data processing and is not the ideal service for processing and storing photos and metadata in this use case. Option D involves manual scaling and management of EC2 instances, which is less flexible and more labor-intensive compared to the serverless nature of Lambda. It may not efficiently handle the varying number of concurrent users and can introduce higher operational overhead. In conclusion, option C provides the best solution for scaling the application to meet the needs of the growing user base by leveraging the scalability and durability of Lambda, S3, and DynamoDB.
Comment: Ans C - as well explained by cookieMr (1yr 2mth ago): "Solution C offloads the photo processing to Lambda. Storing the photos in S3 ensures scalability and durability, while keeping the metadata in DynamoDB allows for efficient querying of the associated information. Option A does not provide an appropriate solution for storing the photos, as DynamoDB is not suitable for storing large binary data like images. ...option C provides the best solution for scaling the application to meet the needs of the growing user base by leveraging the scalability and durability of Lambda, S3, and DynamoDB."
Comment: DynamoDB should not be used for storing images and files in general. Answer should be C.
Comment: DynamoDB is not designed for storing large objects like photos. Amazon S3 is the correct storage service for photos.
Comment: s3 bucket is good option to store images
Comment: C is correct answer.
Comment: C. DB is for data, not for photos. Kinesis doesn't store, it processes streaming.
Comment: DynamoDB items max size is 400kb. so A cannot be right answer. Correct Answer is C
Comment: Max size for DDB entry is 400KB.
Comment: Images (Object) should go in S3 and metadata should go in database (DynamoDB)
Comment: Solution C offloads the photo processing to Lambda. Storing the photos in S3 ensures scalability and durability, while keeping the metadata in DynamoDB allows for efficient querying of the associated information.
Comment: Solution C
Comment: i think is only a confusion of the admin, because it has more sense to store the photos in a S3 bucket is logic.
Comment: A does not store data.
Comment: I stopped at option C
Comment: c is correct
Comment: Option A (creating a NAT gateway) would not meet the requirement since it still involves sending traffic to S3 over the internet. NAT gateway is used for outbound internet connectivity from private subnets, but it doesn't provide a private route for accessing S3. Option B (configuring security groups) focuses on controlling outbound traffic using security groups. While it can restrict outbound traffic, it doesn't provide a private route for accessing S3. Option D (setting up Direct Connect) involves establishing a dedicated private network connection between the on-premises environment and AWS. While it offers private connectivity, it is more suitable for hybrid scenarios and not necessary for achieving private access to S3 within the VPC. In summary, option C provides a straightforward solution by moving the EC2 instances to private subnets, creating a VPC endpoint for S3, and linking the endpoint to the route table for private subnets. This ensures that file transfer traffic between the EC2 instances and S3 remains within the private network without going over the internet.
Comment: Ans C - I was going for Ans D... ...but as well explained by Buruguduystunstugudunstuy (1 year, 8 mth ago), C is simpler: "Option C: Move the EC2 instances to private subnets. Create a VPC endpoint for Amazon S3, and link the endpoint to the route table for the private subnets. To meet the new requirement of transferring files over a private route, the EC2 instances should be moved to private subnets, which do not have direct access to the internet. This ensures that the traffic for file transfers does not go over the internet. "Option D (Remove the internet gateway from the VPC and set up an AWS Direct Connect connection) would not be necessary, as the requirement can be met by simply creating a VPC endpoint for Amazon S3 and routing traffic through it."
Comment: C is the correct answer.
Comment: C. Move the EC2 instances to private subnets. Create a VPC endpoint for Amazon S3, and link the endpoint to the route table for the private subnets.
Comment: Move the EC2 instances to private subnets. Create a VPC endpoint for Amazon S3, and link the endpoint to the route table for the private subnets.
Comment: link VPC endpoint in route tables ---- EC2 instance to communicate S3 with a private connection in VPC
Comment: According to the well-designed framework, option C is the safest and most efficient option.
Comment: The correct answer is C. Move the EC2 instances to private subnets. Create a VPC endpoint for Amazon S3, and link the endpoint to the route table for the private subnets. To meet the new requirement of transferring files over a private route, the EC2 instances should be moved to private subnets, which do not have direct access to the internet. This ensures that the traffic for file transfers does not go over the internet. To enable the EC2 instances to access Amazon S3, a VPC endpoint for Amazon S3 can be created. VPC endpoints allow resources within a VPC to communicate with resources in other services without the traffic being sent over the internet. By linking the VPC endpoint to the route table for the private subnets, the EC2 instances can access Amazon S3 over a private connection within the VPC.
Comment: Option A (Create a NAT gateway) would not work, as a NAT gateway is used to allow resources in private subnets to access the internet, while the requirement is to prevent traffic from going over the internet. Option B (Configure the security group for the EC2 instances to restrict outbound traffic) would not achieve the goal of routing traffic over a private connection, as the traffic would still be sent over the internet. Option D (Remove the internet gateway from the VPC and set up an AWS Direct Connect connection) would not be necessary, as the requirement can be met by simply creating a VPC endpoint for Amazon S3 and routing traffic through it.
Comment: How about the question of moving the instances across subnets. Because according to AWS you can't do it. https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/#:~:text=It%27s%20not%20possible%20to%20move,%2C%20Availability%20Zone%2C%20or%20VPC. Kindly clarify. Maybe I miss something.
Comment: You can't just change the subnet in instance settings, but this article mentions how you CAN move the instance manually.
Comment: Option C
Comment: C is correct. There is no requirement for public access from internet. Application must be moved in Private subnet. This is a prerequisite in using VPC endpoints with S3 https://aws.amazon.com/blogs/storage/managing-amazon-s3-access-with-vpc-endpoints-and-s3-access-points/
Comment: C is correct
Comment: Use VPC endpoint
Comment: User VPC endpoint and make the EC2 private
Comment: Use VPC endpoint
Comment: VPC endpoint is the best choice to route S3 traffic without traversing internet. Option A alone can't be used as NAT Gateway requires an Internet gateway for outbound internet traffic. Option B would still require traversing through internet and option D is also not a suitable solution
Comment: A -> We can configure CloudFront to require HTTPS from clients (enhanced security) https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html D -> storing static website on S3 provides scalability and less operational overhead, then configuration of Application LB and EC2 instances (hence E is out) B is out since AWS WAF Web ACL does not to provide HTTPS functionality, but to protect HTTPS only.
Comment: agree with A and D static website -> obviously S3, and S3 is super scalable CDN -> CloudFront obviously as well, and with HTTPS security is enhanced. B does not make sense because you are not replacing the CDN with anything, E works too but takes too much effort and compared to S3, S3 still wins in term of scalability. plus why use EC2 when you are only hosting static website
Comment: Amazon CloudFront is for Securely deliver content with low latency and high transfer speeds But what about the SQLinjection XSS attacks? we use WAF and olso use HTTPS https://www.f5.com/glossary/web-application-firewall-waf#:~:text=A%20WAF%20protects%20your%20web,and%20what%20traffic%20is%20safe. WAF protects your web apps by filtering, monitoring, and blocking any malicious HTTP/S traffic traveling to the web application, and prevents any unauthorized data from leaving the app. Answer is WAF Not Cloudfront
Comment: does not need to have any dynamic content available
Comment: A and D is the safest combination.
Comment: these answers are the most common use case for real companies, is like the answers that have more sense
Comment: Web Application Firewall creates rules to block attacks, but it does not create HTTPS. It can only allow HTTPS inbound traffic.
Comment: Scalability, enhanced security and less operational overhead = CloudFront with HTTPS Scalability and less operational overhead = S3 bucket with static website hosting
Comment: A. Amazon CloudFront provides scalable content delivery with HTTPS functionality, meeting security and scalability requirements. D. Deploying the website on an Amazon S3 bucket with static website hosting reduces operational overhead by eliminating server maintenance and patching. Why other options are incorrect: B. AWS WAF does not provide HTTPS functionality or address patching and maintenance. C. Using AWS Lambda introduces complexity and does not directly address patching and maintenance. E. Managing EC2 instances and an Application Load Balancer increases operational overhead and does not minimize patching and maintenance tasks. In summary, configuring Amazon CloudFront for HTTPS and deploying on Amazon S3 with static website hosting provide security, scalability, and reduced operational overhead.
Comment: AD A for enhanced security D for static content
Comment: LEAST operational overhead = Serverless https://aws.amazon.com/serverless/
Comment: AD misses the operational part, how can the app work without a lambda function, an EC2 instance or something?
Comment: people do not seem to get the LEAST OPERATIONAL OVERHEAD statement, many people keep voting for options that bring far too Op work
Comment: A for enhanced security D for static content
Comment: Since Amazon S3 is unlimited and you pay as you go so it means there will be no limit to scale as long as your data is going to grow, so D is one of the correct answers and another correct answer is A, because of this: https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html so my answer is AD.
Comment: I vote A & C for the reason being least operational overhead.
Comment: Here a perfect explanation: https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/
Comment: Simple and secure
Comment: D. Create the new website and an Amazon S3 bucket. Deploy the website on the S3 bucket with static website hosting enabled. A. Configure Amazon CloudFront in front of the website to use HTTPS functionality. By deploying the website on an S3 bucket with static website hosting enabled, the company can take advantage of the high scalability and cost-efficiency of S3 while also reducing the operational overhead of managing and patching a CMS. By configuring Amazon CloudFront in front of the website, it will automatically handle the HTTPS functionality, this way the company can have a secure website with very low operational overhead.
Comment: answer is A https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html > You can configure a CloudWatch Logs log group to stream data it receives to your Amazon OpenSearch Service cluster in NEAR REAL-TIME through a CloudWatch Logs subscription least overhead compared to kinesis
Comment: good enough for me
Comment: Zerotn3 is right! There should be a Lambda for writing into ES
Comment: Great link. Convinced me
Comment: Option A (Configure a CloudWatch Logs subscription to stream the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service)) is not a suitable option, as a CloudWatch Logs subscription is designed to send log events to a destination such as an Amazon Simple Notification Service (Amazon SNS) topic or an AWS Lambda function. It is not designed to write logs directly to Amazon Elasticsearch Service (Amazon ES).
Comment: that is not true, you can stream logs from CloudWatch Logs directly to OpenSearch
Comment: The correct answer is C: Create an Amazon Kinesis Data Firehose delivery stream. Configure the log group as the delivery stream source. Configure Amazon OpenSearch Service (Amazon Elasticsearch Service) as the delivery stream's destination. This solution uses Amazon Kinesis Data Firehose, which is a fully managed service for streaming data to Amazon OpenSearch Service (Amazon Elasticsearch Service) and other destinations. You can configure the log group as the source of the delivery stream and Amazon OpenSearch Service as the destination. This solution requires minimal operational overhead, as Kinesis Data Firehose automatically scales and handles data delivery, transformation, and indexing.
Comment: Option A: Configure a CloudWatch Logs subscription to stream the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service) would also work, but it may require more operational overhead as you would need to set up and manage the subscription and ensure that the logs are delivered in near-real time. Option B: Create an AWS Lambda function. Use the log group to invoke the function to write the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service) would also work, but it may require more operational overhead as you would need to set up and manage the Lambda function and ensure that it scales to handle the incoming logs. Option D: Install and configure Amazon Kinesis Agent on each application server to deliver the logs to Amazon Kinesis Data Streams. Configure Kinesis Data Streams to deliver the logs to Amazon OpenSearch Service (Amazon Elasticsearch Service) would also work, but it may require more operational overhead as you would need to install and configure the Kinesis Agent on each application server and set up and manage the Kinesis Data Streams.
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: ANSWER A https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html You can use CloudWatch or Kinesis, but in the Kinesis description it never says real time, however in the Cloudwatch description it does say Real time ""You can load streaming data from CloudWatch Logs to your OpenSearch Service domain by using a CloudWatch Logs subscription . For information about Amazon CloudWatch subscriptions, see Real-time processing of log data with subscriptions.""
Comment: C for sure Simplicity: Kinesis Data Firehose is a managed service that handles the task of capturing, transforming, and loading data into destinations like Amazon OpenSearch Service. This eliminates the need for complex configuration and management. Scalability: Kinesis Data Firehose can automatically scale to handle varying data volumes, ensuring that logs are ingested in near-real time. Cost-effectiveness: Kinesis Data Firehose is a pay-as-you-go service, making it a cost-effective option for log ingestion and analysis.
Comment: I think C is correct because the cloud watch subscription can't stream directly to OpenSearch, it is via Lambda, SNS, FireHouse,....
Comment: You can configure a log group in Amazon CloudWatch Logs, so you can stream data to your Amazon OpenSearch Service cluster in near real-time.
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: Configure a CloudWatch Logs log group to stream data directly to the Amazon OpenSearch Service cluster. This can be done through a CloudWatch Logs subscription, which allows for real-time processing of log data.
Comment: A is the correct answer, CloudWatch offers a subscription where you can stream data to other AWS services
Comment: Correct Answer: C. Create an Amazon Kinesis Data Firehose delivery stream. Configure the log group as the delivery stream's source. Configure Amazon OpenSearch Service (Amazon Elasticsearch Service) as the delivery stream's destination. Explanation: Amazon Kinesis Data Firehose is a fully managed service for delivering real-time streaming data to destinations such as Amazon OpenSearch Service. It requires minimal setup and management, making it a low-overhead solution. By configuring the log group as the source for the Kinesis Data Firehose delivery stream and Amazon OpenSearch Service as the destination, logs can be delivered in near-real time with built-in reliability and scalability.
Comment: easy enough to figure out. Option A
Comment: A for sure
Comment: It can natively connect to CloudWatch Logs as a source and OpenSearch Service as a destination, handling the delivery of logs efficiently and with minimal setup. This approach offers the least operational overhead by simplifying the data transfer pipeline with automatic scaling and error handling.
Comment: You can configure a CloudWatch Logs log group to stream data it receives to your Amazon OpenSearch Service cluster in near real-time through a CloudWatch Logs subscription. here is the link/; https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: Answer A. This doc clarifies the subject: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: A is correct You can configure a CloudWatch Logs log group to stream data it receives to your Amazon OpenSearch Service cluster in near real-time through a CloudWatch Logs subscription. https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: You can configure a CloudWatch Logs log group to stream data it receives to your Amazon OpenSearch Service cluster in near real-time through a CloudWatch Logs subscription. This is the solution that requires the least operational overhead. https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
Comment: A, You can configure a CloudWatch Logs log group to stream data it receives to your Amazon OpenSearch Service cluster in near real-time through a CloudWatch Logs subscription
Comment:
the cost of S3
Comment: Amazon S3 (Simple Storage Service) is a highly scalable and cost-effective storage service. It is well-suited for storing large amounts of data, such as the 900 TB of text documents mentioned in the scenario. S3 provides high durability, availability, and performance. Option A (Amazon EBS) is block storage designed for individual EC2 instances and may not scale as seamlessly and cost-effectively as S3 for large amounts of data. Option B (Amazon EFS) is a scalable file storage service, but it may not be the most cost-effective option compared to S3, especially for the anticipated storage size of 900 TB. Option C (Amazon OpenSearch Service) is a search and analytics service and may not be suitable as the primary storage solution for the text documents. In summary, Amazon S3 is the recommended choice as it offers high scalability, cost-effectiveness, and durability for storing the large repository of text documents required by the web application.
Comment: Ans D - Amazon S3 is highly scalable, cost-effective storage service, well-suited for large amounts of data. It is highly durable, highly available, and offers good performance. By comparison, EFS (option B) could do it but is more expensive...
Comment: S3 can be a good option for storing text documents. It allows users to store any file type as objects. (documents, videos, images)
Comment: Using EFS would obviously be the optimal case, we have to use s3 to fulfill the cost efficiency requirement.
Comment: Option A : EBS can't be multi-AZ Option B: EFS is expensive Option C: ElasticSearch is not for storing
Comment: D is the only real solution here. S3 is the cheapest option for storage and it can scale indefinitely.
Comment: MOST cost-effective = S3 (unless explicitly stated in the requirements)
Comment: 900 in the question to divert our Thinking.When you have keyword least in question S3 will be only thing we should look
Comment: EFS and S3 meet the requirements but S3 is a better option because it is cheaper.
Comment: MOST cost-effective = S3 (unless explicitly stated in the requirements)
Comment: S3 is the cheapest and most scalable.
Comment: Now in OpenSearch you can reach at 3 PB so option C is better. With S3 in an intensive scenario the costs of retriving the buckets could be high. Yes OpenSearch is NOT cheap but this has to be analysed carefully. So, I opt "C" to increase the discussion. With UltraWarm, you can retain up to 3 PB of data on a single Amazon OpenSearch Service cluster, while reducing your cost per GB by nearly 90% compared to the warm storage tier. You can also easily query and visualize the data in your Kibana interface (version 7.10 and earlier) or OpenSearch Dashboards. Analyze both your recent (weeks) and historical (months or years) log data without spending hours or days restoring archived logs. https://aws.amazon.com/es/opensearch-service/features/
Comment: EFS is a good option but expensive alongside S3 and customer concerned about cost - thus: S3 (D)
Comment: I wonder why people choose S3, yet S3 max capacity is 5TB 🤔.
Comment: My bad, the 5TB limit is for individual files. S3 has virtually unlimited storage capacity.
Comment: A. It is Not a block storage B. It is Not a file storage C. Opensearch is useful but can only accommodate up to 600TiB and is mainly for search and anaytics. D. S3 is more cost effective than all and can handle all objects like Block, File or Text.
Comment: D. Amazon S3 Amazon S3 is an object storage service that can store and retrieve large amounts of data at any time, from anywhere on the web. It is designed for high durability, scalability, and cost-effectiveness, making it a suitable choice for storing a large repository of text documents. With S3, you can store and retrieve any amount of data, at any time, from anywhere on the web, and you can scale your storage up or down as needed, which will help to meet the demand of the web application. Additionally, S3 allows you to choose between different storage classes, such as standard, infrequent access, and archive, which will enable you to optimize costs based on your specific use case.
Comment: If you want to use AWS WAF across accounts, accelerate WAF configuration, automate the protection of new resources, use Firewall Manager with AWS WAF
Comment: they didn't mention multiple accounts! only 2 regoins
Comment: wtf? the question says "to protect these API Gateway managed REST APIs across multiple accounts from SQL injection and cross-site scripting attack"
Comment: B is wrong: AWS Firewall Manager cannot create security policies across regions. Q: Can I create security policies across regions? No, AWS Firewall Manager security policies are region specific. Each Firewall Manager policy can only include resources available in that specified AWS Region. You can create a new policy for each region where you operate. https://aws.amazon.com/firewall-manager/faqs/#:~:text=No%2C%20AWS%20Firewall%20Manager%20security,in%20that%20specified%20AWS%20Region.
Comment: AWS Firewall Manager is integrated with AWS Organizations so you can enable AWS WAF rules, AWS Shield Advanced protections, VPC security groups, AWS Network Firewalls, and Amazon Route 53 Resolver DNS Firewall rules across multiple AWS accounts and resources from a single place.
Comment: That's why B says that you "set up AWS Firewall Manager IN BOTH REGIONS". Still you can "centrally configure" WAF per region, so that you don't have to attach WAF to every individual API.
Comment: B Using AWS WAF has several benefits. Additional protection against web attacks using criteria that you specify. You can define criteria using characteristics of web requests such as the following: Presence of SQL code that is likely to be malicious (known as SQL injection). Presence of a script that is likely to be malicious (known as cross-site scripting). AWS Firewall Manager simplifies your administration and maintenance tasks across multiple accounts and resources for a variety of protections. https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
Comment: Q: Can I create security policies across regions? No, AWS Firewall Manager security policies are region specific. Each Firewall Manager policy can only include resources available in that specified AWS Region. You can create a new policy for each region where you operate. So you could not centrally (i.e. in one place) configure policies, you would need to do this is each region
Comment: "Centrally" on the Firewall Manager per region, as opposed to individually for every single API.
Comment: I recently purchased the Multiwood Ergonomic Office Chair, and it's a game changer! The comfort and support it provides have transformed my work-from-home experience. Plus, the value for the quality is unbeatable highly recommended for anyone looking to enhance their workspace.
Comment: B for sure Centralized management: AWS Firewall Manager allows you to centrally manage AWS WAF rules across multiple accounts and regions. This simplifies the configuration and management process. Consistent security policies: You can enforce consistent security policies across all your API Gateway APIs, ensuring that they are protected from the same threats. Scalability: AWS Firewall Manager can handle a large number of accounts and resources, making it suitable for global companies with many API Gateway APIs.
Comment: Ans A - "With AWS WAF, you can create security rules that control bot traffic and block common attack patterns such as SQL injection or cross-site scripting (XSS). Use cases. Filter web traffic." https://aws.amazon.com › waf None of the other options can do it.
Comment: AWS WAF helps you to protect your application against common web exploits and bots that can affect availability, compromise security or consume excessive resources. You can create security rules that will control bot traffic and common attacks like SQL injection or Cross-site scripting (XSS)
Comment: A is valid, but B achieves the least operational overhead.
Comment: WAF deals well with the types of attacks mentioned. XSS and SQL Injection are both app level attacks hence needs a WAF.
Comment: B Option A involves setting up AWS WAF in both regions and associating regional web ACLs with an API stage. While this can provide the necessary protection, it requires more manual configuration in each region, potentially leading to more administrative effort, especially if there are updates or changes needed to be made across multiple regions. Therefore, Option B is likely to require the least amount of administrative effort.
Comment: Original architecture does not have WAFs. B assumes there are WAFs already in place and why would you want to deploy a Firewall Manager to manage 1 Firewall? it adds unnecessary administrative tasks and costs for a tool that is not needed. You would want that if you were managing 10+ Firewalls not just one. A makes the most sense.
Comment: B is the answer
Comment: B is basically A but with least admin overhead.
Comment: Are AWS firewall Manager security policies region specific? Q: Can I create protection policies across regions? No, Amazon Firewall Manager protection policies are region specific. Each Firewall Manager policy can only include resources available in that specified Amazon Web Services Region. You can create a new policy for each region where you operate.
Comment: AW FW manager demo: https://youtu.be/fwFHTxtSN2M
Comment: For "SQL injection and cross-site scripting attacks" use AWS WAF: https://aws.amazon.com/waf/features/
Comment: Y, but WAF is also involved in B, just centrally configured by Firewall Manager
Comment: the question mentioned 2 regions not 2 accounts WAF is more suitable here with less effort than Firewall Manager!
Comment: https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html#:~:text=AWS%20Firewall%20Manager%20simplifies,new%20accounts%20and%20resources.
Comment: B is the correct one for seld manage DNS If need to use Route53, ALB (layar 7 ) needs to be used as end points for 2 reginal x 3 EC2s, if it the case answer would be the option 4
Comment: After reading the discussion I think the right answer is B, as the service they use is DNS it does not make sense using a cloudfront distribution for this. The scenario would be different if the service were HTTP/HTTPS.
Comment: Just to complete my previous comment. If the scenario were that the company uses HTTP/HTTPS service, then the correct answer (as the original dokaedu message mentions) would be option D)
Comment: Why I need replace NLB to ALB?
Comment: Who said that?
Comment: for me it is B
Comment: Ans B - "AWS Global Accelerator improves the availability and performance of your applications for global users by routing traffic to the optimal endpoint based on performance and policies." https://aws.amazon.com › global-accelerator › faqs
Comment: i choose a previous until i checked google that tells me "DNS is an Application-layer protocol"
Comment: A seems the right answer.
Comment: Not A: CloudFront is not for DNS Not C: Involves CloudFront which is not needed, otherwise would work but ignore the NLBs Not D: ALB can't handle DNS Leaves B
Comment: Keyword- AWS global accelerator = Super cop (who direct the traffic and give you the best way to reach your destination) Geolocation is use for showing web content as you want to show your web content to particular country or continent. Geolocation has nothing to do with traffic.
Comment: Route 53 geolocation has nothing to do with traffic in the sense that it does not affect the amount or speed of traffic that reaches your resources. It only affects how Route 53 responds to DNS queries based on the location of your users.
Comment: Option B. Create a standard accelerator in AWS Global Accelerator. Establish endpoint groups in us-west-2 and eu-west-1. Add two NLBs as endpoints of the endpoint group. AWS Global Accelerator is a network service that can provide a global traffic management solution. By creating a standard accelerator in AWS Global Accelerator, you can guide user traffic to the endpoint closest to them, thereby improving the performance and availability of the application. In this case, you can establish endpoint groups in the us-west-2 and eu-west-1 regions, and add two NLBs as endpoints. In this way, no matter where the user is located, their requests will be routed to the EC2 instance closest to them, thereby improving the performance and availability of DNS resolution. In addition, this design can also provide flexibility and scalability to handle a large amount of traffic. Therefore, this solution can meet your needs.
Comment: Global Accelerator: AWS Global Accelerator is designed to improve the availability and performance of applications by using static IP addresses (Anycast IPs) and routing traffic over the AWS global network infrastructure. Endpoint Groups: By creating endpoint groups in both the us-west-2 and eu-west-1 Regions, the company can effectively distribute traffic to the NLBs in both Regions. This improves availability and allows traffic to be directed to the closest Region based on latency.
Comment: Key: route traffic to all the EC2 instances
Comment: B. Create a standard accelerator in AWS Global Accelerator. Create endpoint groups in us-west-2 and eu-west-1. Add the two NLBs as endpoints for the endpoint groups. Here's why this option is the most suitable: Global Accelerator: AWS Global Accelerator is designed to improve the availability and performance of applications by using static IP addresses (Anycast IPs) and routing traffic over the AWS global network infrastructure. Endpoint Groups: By creating endpoint groups in both the us-west-2 and eu-west-1 Regions, the company can effectively distribute traffic to the NLBs in both Regions. This improves availability and allows traffic to be directed to the closest Region based on latency.
Comment: B is the best solution to route traffic to all the EC2 instances across regions. The key reasons are: AWS Global Accelerator allows routing traffic to endpoints in multiple AWS Regions. It uses the AWS global network to optimize availability and performance. Creating an accelerator with endpoint groups in us-west-2 and eu-west-1 allows traffic to be distributed across both regions. Adding the NLBs in each region as endpoints allows the traffic to be routed to the EC2 instances behind them. This provides improved performance and availability compared to just using Route 53 geolocation routing.
Comment: B route requests to one of the two NLBs --> hence AD out / Attach Elastic IP addresses --> who will pay for it?
Comment: Option B offers a global solution by utilizing Global Accelerator. By creating a standard accelerator and configuring endpoint groups in both Regions, the company can route traffic to all the EC2 across multiple regions. Adding the two NLBs as endpoints ensures that traffic is distributed effectively. Option A does not directly address the requirement of routing traffic to all EC2 instances. It focuses on routing based on geolocation and using CloudFront as a distribution, which may not achieve the desired outcome. Option C involves managing Elastic IP addresses and routing based on geolocation. However, it may not provide the same level of performance and availability as AWS Global Accelerator. Option D focuses on ALBs and latency-based routing. While it can be a valid solution, it does not utilize AWS Global Accelerator and may require more configuration and management compared to option B.
Comment: Correctly is B. if it is self-managed DNS, you cannot use Route 53. There can be only 1 DNS service for the domain.
Comment: For self-managed DNS solution: https://aws.amazon.com/blogs/security/how-to-protect-a-self-managed-dns-service-against-ddos-attacks-using-aws-global-accelerator-and-aws-shield-advanced/
Comment: Re-wording the correct explanations here: if it is self-managed DNS, you cannot use Route 53. There can be only 1 DNS service for the domain. If the question didn't mentioned self-managed DNS and asked for optimal solution, then D is correct.
Comment: "You can enable encryption for an Amazon RDS DB instance when you create it, but not after it's created. However, you can add encryption to an unencrypted DB instance by creating a snapshot of your DB instance, and then creating an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot to get an encrypted copy of your original DB instance." https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/encrypt-an-existing-amazon-rds-for-postgresql-db-instance.html
Comment: thats crazy cuh the more you know ig
Comment: How can A gurantee future encryption?
Comment: Once DB is encrypted, newer snapshots and read replicas will also be encrypted.
Comment: I agree, there is no reason to copy all of the snapshots and ecnrypt them all. You just need one encrypted snapshot, moving forward they will all be encrypted. C is close but I think there is no reason to copy all the snapshots plural. There is a wizard to go through and select the snapshot to encrypt. "In the Amazon RDS console navigation pane, choose Snapshots, and select the DB snapshot you created. For Actions, choose Copy Snapshot. Provide the destination AWS Region and the name of the DB snapshot copy in the corresponding fields. Select the Enable Encryption checkbox. For Master Key, specify the KMS key identifier to use to encrypt the DB snapshot copy. Choose Copy Snapshot. For more information, see Copying a snapshot in the Amazon RDS documentation". What if you had 30 snapshotS? You just need to do it once.
Comment: In simple terms, you double it the affort of your work and spending money by creating unnessary snapshots... so A is the best choice
Comment: Ans A - I must admit almsot put Ans C, but re-reading question and seeing comments its clear that encryption is needed "moving forward" so C is overkill...
Comment: Replacing a snapshots creates a new one instead of restoring the old one.
Comment: I feel this is a bit tricky in the way the question is asked, but C implies that you are encrypting the snapshot. You are not. It is the DB that receives a KMS key upon restoring, but the snapshot is still unencrypted
Comment: Correct. Please visit for more details. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/encrypt-an-existing-amazon-rds-for-postgresql-db-instance.html
Comment: AWS RDS does not support direct restoration of an encrypted snapshot to an existing unencrypted DB instance. When you restore a snapshot, it creates a new DB instance with the same configuration as the original instance.
Comment: What's wrong with C is: "Copy the snapshots and enable encryption"
Comment: key: snapshots
Comment: I was undecided if to choose A or C. But since you can't restore a snapshot to an existing instance C is out. You can only create a new one. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html#:~:text=You%20can%27t%20restore%20from%20a%20DB%20snapshot%20to%20an%20existing%20DB%20instance%3B%20a%20new%20DB%20instance%20is%20created%20when%20you%20restore.
Comment: A makes sence
Comment: A. Replacing the existing DB instance with an encrypted snapshot can result in downtime and potential data loss during migration. B. Creating a new encrypted EBS volume for snapshots does not address the encryption of the DB instance itself. D. Copying snapshots to an encrypted S3 bucket only encrypts the snapshots, but does not address the encryption of the DB instance. Option C is the most suitable as it involves copying and encrypting the snapshots using AWS KMS, ensuring encryption for both the database and snapshots.
Comment: From the question: "...What should a solutions architect do to ensure the database and snapshots are always encrypted moving forward?" I think the question is about encrypting current and future snapshots instead of the old snapshots.
Comment: If daily snapshots are taken from the daily DB instance. Why create another copy? You just need to encrypt the latest daily DB snapshot and the restore from the existing encrypted snapshot.
Comment: You can't restore from a DB snapshot to an existing DB instance; a new DB instance is created when you restore.
Comment: A and C are almost similar except that A is latest snapshot, while C is snapshots (all the snapshots). I don't see any other difference btw those two options. Option A is clearly the correct on as all you need is the latest snapshot.
Comment: I agree, in the wizard you would select ONE SNAPSHOT (singular in A), not all of the SNAPSHOTS (Plural in C)
Comment: A You can only encrypt an Amazon RDS DB instance when you create it, not after the DB instance is created. However, because you can encrypt a copy of an unencrypted snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance, and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
Comment: Encryption is enabled during the Copy process itself. https://repost.aws/knowledge-center/encrypt-rds-snapshots
Comment: C is the more complete answer as you need KMS to encrypt the snapshot copy prior to restoring it to the Database instance.
Comment: BUT you can't restore encrypted snapshot to an existing DB instance.Only no NEW DB (not an existing one). The procedure described in this way: "(...) you can add encryption to an unencrypted DB instance by creating a snapshot of your DB instance, and then creating an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot to get an encrypted copy of your original DB instance." refers to create a NEW DB instance (this encrypted), never restoring in a existing one. The RDB engine understands that restoring from a encrypted snapshot is form create an encrypted NEW database.
Comment: If you are a developer who needs to digitally sign or verify data using asymmetric keys, you should use the service to create and manage the private keys you'll need. If you're looking for a scalable key management infrastructure to support your developers and their growing number of applications, you should use it to reduce your licensing costs and operational burden... https://aws.amazon.com/kms/faqs/#:~:text=If%20you%20are%20a%20developer%20who%20needs%20to%20digitally,a%20broad%20set%20of%20industry%20and%20regional%20compliance%20regimes.
Comment: Most documented answers. Thank you, 123jhl0.
Comment: The correct answer is Option B. To reduce the operational burden, the solutions architect should use AWS Key Management Service (AWS KMS) to protect the encryption keys. AWS KMS is a fully managed service that makes it easy to create and manage encryption keys. It allows developers to easily encrypt and decrypt data in their applications, and it automatically handles the underlying key management tasks, such as key generation, key rotation, and key deletion. This can help to reduce the operational burden associated with key management.
Comment: Ans B - AWS KMS does it all as a managed service...
Comment: to reduce the operational burden, option B is the best choice.
Comment: The correct answer is Option B. To reduce the operational burden, the solutions architect should use AWS Key Management Service (AWS KMS) to protect the encryption keys
Comment: AWS KMS handles the encryption key management, rotation, and auditing. This removes the undifferentiated heavy lifting for developers. KMS integrates natively with many AWS services like S3, EBS, RDS for encryption. This makes it easy to encrypt data. KMS scales automatically as key usage increases. Developers don't have to worry about provisioning key infrastructure. Fine-grained access controls are available via IAM policies and grants. KMS is secure by default. Features like envelope encryption make compliance easier for regulated workloads. AWS handles the hardware security modules (HSMs) for cryptographic key storage
Comment: The main reasons are: AWS KMS handles the encryption key management, rotation, and auditing. This removes the undifferentiated heavy lifting for developers. KMS integrates natively with many AWS services like S3, EBS, RDS for encryption. This makes it easy to encrypt data. KMS scales automatically as key usage increases. Developers don't have to worry about provisioning key infrastructure. Fine-grained access controls are available via IAM policies and grants. KMS is secure by default. Features like envelope encryption make compliance easier for regulated workloads. AWS handles the hardware security modules (HSMs) for cryptographic key storage
Comment: By utilizing AWS KMS, the company can offload the operational responsibilities of key management, including key generation, rotation, and protection. AWS KMS provides a scalable and secure infrastructure for managing encryption keys, allowing developers to easily integrate encryption into their applications without the need to manage the underlying key infrastructure. Option A (MFA), option C (ACM), and option D (IAM policy) are not directly related to reducing the operational burden of key management. While these options may provide additional security measures or access controls, they do not specifically address the scalability and management aspects of a key management infrastructure. AWS KMS is designed to simplify the key management process and is the most suitable option for reducing the operational burden in this scenario.
Comment: B is correct.
Comment: Option B
Comment: B is correct
Comment: B is correct
Comment: If you are responsible for securing your data across AWS services, you should use it to centrally manage the encryption keys that control access to your data. If you are a developer who needs to encrypt data in your applications, you should use the AWS Encryption SDK with AWS KMS to easily generate, use and protect symmetric encryption keys in your code.
Comment: This issue is solved by SSL offloading, i.e. by moving the SSL termination task to the ALB. https://aws.amazon.com/blogs/aws/elastic-load-balancer-support-for-ssl-termination/
Comment: The correct answer is D. To increase the application's performance, the solutions architect should import the SSL certificate into AWS Certificate Manager (ACM) and create an Application Load Balancer with an HTTPS listener that uses the SSL certificate from ACM. An Application Load Balancer (ALB) can offload the SSL termination process from the EC2 instances, which can help to increase the compute capacity available for the web application. By creating an ALB with an HTTPS listener and using the SSL certificate from ACM, the ALB can handle the SSL termination process, leaving the EC2 instances free to focus on running the web application.
Comment: Ans D - well explained by Buruguduystunstugudunstuy (1yr, 8mth): "To increase the application's performance, the solutions architect should import the SSL certificate into AWS Certificate Manager (ACM) and create an Application Load Balancer with an HTTPS listener that uses the SSL certificate from ACM. An Application Load Balancer (ALB) can offload the SSL termination process from the EC2 instances, which can help to increase the compute capacity available for the web application. By creating an ALB with an HTTPS listener and using the SSL certificate from ACM, the ALB can handle the SSL termination process, leaving the EC2 instances free to focus on running the web application."
Comment: D is the correct answer.
Comment: This issue is solved by SSL offloading, i.e. by moving the SSL termination task to the ALB. https://aws.amazon.com/blogs/aws/elastic-load-balancer-support-for-ssl-termination
Comment: The key reasons are: Using an Application Load Balancer with an HTTPS listener allows SSL termination to happen at the load balancer layer. The EC2 instances behind the load balancer receive only unencrypted traffic, reducing load on them. Importing the custom SSL certificate into ACM allows the ALB to use it for HTTPS listeners. This removes the need to install and manage SSL certificates on each EC2 instance. ALB handles the SSL overhead and scales automatically. The EC2 fleet focuses on app logic. Options A, B, C don't offload SSL overhead from the EC2 instances themselves.
Comment: By using ACM to manage the SSL certificate and configuring an ALB with HTTPS listener, the SSL termination will be handled by the load balancer instead of the web servers. This offloading of SSL processing to the ALB reduces the compute capacity burden on the web servers and improves their performance by allowing them to focus on serving the dynamic web application. Option A suggests creating a new SSL certificate using ACM, but it does not address the SSL termination offloading and load balancing capabilities provided by an ALB. Option B suggests migrating the SSL certificate to an S3 bucket, but this approach does not provide the necessary SSL termination and load balancing functionalities. Option C suggests creating another EC2 instance as a proxy server, but this adds unnecessary complexity and management overhead without leveraging the benefits of ALB's built-in load balancing and SSL termination capabilities. Therefore, option D is the most suitable choice to increase the application's performance in this scenario.
Comment: Why is A wrong?
Comment: Company uses its own SSL certificate. Option A says.. Create a SSL certificate in ACM
Comment: ec2 instances still would be responsible for decrypting traffic and it wouldn't solve load issue
Comment: SSL termination is the process of ending an SSL/TLS connection. This is typically done by a device, such as a load balancer or a reverse proxy, that is positioned in front of one or more web servers. The device decrypts incoming SSL/TLS traffic and then forwards the unencrypted request to the web server. This allows the web server to process the request without the overhead of decrypting and encrypting the traffic. The device then re-encrypts the response from the web server and sends it back to the client. This allows the device to offload the SSL/TLS processing from the web servers and also allows for features such as SSL offloading, SSL bridging, and SSL acceleration.
Comment: Option D to offload the SSL encryption workload
Comment: Due to this statement particularly: "The company has its own SSL certificate" as it's not created from AWS ACM itself.
Comment: D is correct
Comment: agree with D
Comment: Cant be implemented on Lambda because the timeout for Lambda is 15mins and the Job takes 60minutes to complete Answer >> A
Comment: spot instances
Comment: A is the correct answer, we can't use lambda because it's limit is 15 mins.
Comment: There is a chance of interrupting the jobs, but as they can be started and stopped at any given time, the MOST COST effective is going for Spot.
Comment: Spot Instances provide significant cost savings for flexible start and stop batch jobs. Purchasing Reserved Instances (B) is better for stable workloads, not dynamic ones. On-Demand Instances (C) are costly and lack potential cost savings like Spot Instances. AWS Lambda (D) is not suitable for long-running batch jobs.
Comment: key: can be started and stopped at any given time with no negative impact
Comment: Spot can do that
Comment: The key reasons are: Spot can provide significant cost savings (up to 90%) compared to On-Demand. Since the job is stateless and can be stopped/restarted anytime, the intermittent availability of Spot is not an issue. Spot supports the same instance types as On-Demand, so optimal instance types can be chosen. For a 60+ minute batch job, the chance of Spot interruption is low. But if it happens, the job can just be restarted. Reserved Instances don't offer any advantage for a highly dynamic job like this. Lambda is not a good fit given the long runtime requirement.
Comment: Spot Instances provide significant cost savings for flexible start and stop batch jobs. Purchasing Reserved Instances (B) is better for stable workloads, not dynamic ones. On-Demand Instances (C) are costly and lack potential cost savings like Spot Instances. AWS Lambda (D) is not suitable for long-running batch jobs.
Comment: A is correct
Comment: Answer A: typically takes upwards of 60 minutes total to complete.
Comment: The correct answer is Option A. To design a scalable and cost-effective solution for the batch processing job, the solutions architect should recommend implementing EC2 Spot Instances. EC2 Spot Instances allow users to bid on spare Amazon EC2 computing capacity and can be a cost-effective solution for stateless, interruptible workloads that can be started and stopped at any time. Since the batch processing job is stateless, can be started and stopped at any time, and typically takes upwards of 60 minutes to complete, EC2 Spot Instances would be a good fit for this workload.
Comment: Spot Instances should be good enough and cost effective because the job can be started and stopped at any given time with no negative impact.
Comment: Option A
Comment: A is correct
Comment: A is the answer
Comment: Answer A for: The EC2 instances and the RDS DB instance should not be exposed to the public internet. Answer D for: The EC2 instances require internet access to complete payment processing of orders through a third-party web service. Answer A for: The application must be highly available.
Comment: D allows public internet access which is not desired. The answer is not d. The most accurate answers are AB
Comment: B is wrong because you can't deploy NAT GW in a private subnet. Correct answer is E (mislabelled as a second D). Stem says that the EC2 instances (!) must not be exposed to the Internet, the Load Balancer can be exposed.
Comment: We will require 2 private subnets, D does mention 1 subnet
Comment: There's two D options ;) second is correct
Comment: why not option B.The EC2 instances can be launched in private subnets across two Availability Zones, and the Application Load Balancer can be deployed in the private subnets. NAT gateways can be configured in each private subnet to provide internet access for the EC2 instances to communicate with the third-party web service.
Comment: B option wrong! NAT gateways must be created in public subnets!!
Comment: I think you are wrong on this. In fact, NAT gateways are typically created in private subnets.
Comment: NAT Gateway can't be used by EC2 instance in the same subnet (only from other subnets)
Comment: A and E! Application has to be highly available while the instance and database should not be exposed to the public internet, but the instances still requires access to the internet. NAT gateway has to be deployed in public subnets in this case while instances and database remain in private subnets in the VPC, therefore answer is (A) and (E). https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html If the instances did not require access to the internet, then the answer could have been (B) to use a private NAT gateway and keep it in the private subnets to communicate only to the VPCs. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
Comment: your link is right but your voting is wrong, should be AD, although that still doesnt explain why 2 NAT gateways
Comment: Because NAT gateways are availability zone specific, if you need HA you will need a NAT gateway in each availability zone.
Comment: cus application has to be HA, if one NAT gateway fails the other could take the traffic
Comment: And A,D - keeps EC2 and RDS private and highly available, but with public front-end (Not sure why Author's highlighted answer is C?)
Comment: AD are correct ans
Comment: AE A because the EC2 can't be exposed to public E because each subnet must reside entirely within one Availability Zone and cannot span zones. source: https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#:~:text=Delete%20a%20subnet-,Subnet%20basics,of%20a%20single%20Availability%20Zone.
Comment: A and D is the best combination, it achieves all of the desired requirements.
Comment: Option A ensures that EC2 instances and RDS DB instance are not exposed to the public internet, as they are launched in private subnets. Auto Scaling group will also ensure high availability of EC2 instances. Option D configures a VPC with a public subnet for the load balancer, and a private subnet for the EC2 instances and RDS DB instance. NAT gateways in both Availability Zones will allow EC2 instances to access the internet for payment processing, while keeping them private.
Comment: A and E (the second D option) .
Comment: There might be error in question. i modified it now CE answer seems to be correct A company runs its two-tier ecommerce website on AWS. The web tier consists of a load balancer that sends traffic to Amazon EC2 instances. The database tier uses an Amazon RDS DB instance. The RDS DB instance should not be exposed to the public internet. The The RDS DB instance require internet access to complete payment processing of orders through a third-party web service. The application must be highly available. Which combination of configuration options will meet these requirements? (Choose two.)
Comment: Use an Auto Scaling group to launch the EC2 instances in private subnets. Deploy an RDS Multi-AZ DB instance in private subnets. This ensures that the EC2 instances and the RDS DB instance are not exposed to the public internet. Configure a VPC with two private subnets and two NAT gateways across two Availability Zones. Deploy an Application Load Balancer in the private subnets. This allows the EC2 instances in private subnets to access the internet for payment processing through the NAT gateways while keeping them private.
Comment: App layer & DB Layer does not expose to Internet -> both in private subnet, access through NAT Gateway It's enough for all requirements!
Comment: AD is right , last one D
Comment: AE Two public subnets = two addresses for ALB = high availability two private subnets with NAT gateway to allow eggress traffic to internet - application tier will be able to complete payment
Comment: AE https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Comment: AE. There are two Ds, the last option should be E.
Comment: AB. should not be exposed to the public internet => private subnet
Comment: EC2 instances should not be exposed to the public Internet, LB should
Comment: CE Highly Available and Secure
Comment: read the question again, it aks to make the ec2 and rds in privete subnet do not mislead others if u are not sure of ur answer C is wrong answer bt 1000000% its A and D
Comment: Why Not C? Because Intelligent Tier the objects are automatically moved to different tiers. The question says "the data from most recent 2 yrs should be highly available and immediately retrievable", which means in intelligent tier , if you activate archiving option(as Option C specifies) , the objects will be moved to Archive tiers(instant to access to deep archive access tiers) in 90 to 730 days. Remember these archive tiers performance will be similar to S3 glacier flexible and s3 deep archive which means files cannot be retrieved immediately within 2 yrs . We have a hard requirement in question which says it should be retreivable immediately for the 2 yrs. which cannot be acheived in Intelligent tier. So B is the correct option imho. Because of the above reason Its possible only in S3 standard and then configure lifecycle configuration to move to S3 Glacier Deep Archive after 2 yrs.
Comment: Mmm.. You can enable Intelligent-Tiering and take advantage of of the infrequent Access tier and thus reducing costs. To avoid moving objects to the deep archive tier before the two years it would be enough to enable ONLY the check "Deep Archive Access tier" and set days to 720 (two years, which is curiously the maximum value), and keep disabled the check "Archive Access tier" to avoid the Intelligent-Tiering move objects to the non-instant retrieval tier. That will work, offcourse this specific configuration is not mention in the question which leaves some doubts about which option is the correct.
Comment: Just to clarify, my previous comment is about how answer B) might be correct and the MOST cheapest option under the correct configuration.
Comment: Sorry, I meant answer C) might be correct
Comment: but your S3 intelligent-tiering will move the object to S3 infrequent access tier which a is a single AZ tier , and then the HA requirement will not be respected
Comment: S3 Standard IA is NOT single AZ. (One-Zone IA is single Az.)
Comment: The issue is with the missing "flag" for 2 years, and not S3 Intelligent Tiering. It needs to be B.
Comment: B is the only right answer. C does not indicate archiving after 2 years. If it did specify 2 years, then C would also be an option.
Comment: Ans B - I did initially think Ans C, but rjam (1 yr, 10 mth ago) quickly quashed that notion: "Why Not C? Because Intelligent Tier the objects are automatically moved to different tiers. The question says "the data from most recent 2 yrs should be highly available and immediately retrievable", which means in intelligent tier , if you activate archiving option(as Option C specifies) , the objects will be moved to Archive tiers(instant to access to deep archive access tiers) in 90 to 730 days. Remember these archive tiers performance will be similar to S3 glacier flexible and s3 deep archive which means files cannot be retrieved immediately within 2 yrs."
Comment: B is correct, because it fits to the requirements and it still cheaper than the option C.
Comment: Stupid question: A: No immediately retrievable and cost B: No immediately retrievable C: Not unpredicted access D: Immediately retrievable but not HA F*ck the guy who made this question
Comment: B is the correct choice, the requirements are very clear, intelligent tiering is used only when we don't have a clear pattern for the access of the data, when it's unpredictable.
Comment: A. We can't move to Glacier immediately as data from last 2 yrs need to be immediately retrievable B. It's the perfect fit: getting HA and instant access (with current solution = S3 std), then moving to Deep Archive after 2 yrs (very cheap) C: Highly expensive because of Intelligent Tiering D: it lacks HA with One Zone
Comment: Data remain in S3 standard storage for 2 years then it will be move to s3 glacier deep archive after 2 year.
Comment: but your S3 intelligent-tiering will move the object to S3 infrequent access tier which a is a single AZ tier , and then the HA requirement will not be respected
Comment: i understand why "B" is more correct than "C" and is because "C" is bad formulated, if in the answer would say "life cycle after 2 years of using intelligent tiring" then it would be the correct answer. so "B" is correct
Comment: I would not opt for C simply because S3IT was specifically designed for scenarios where the access patterns are unknown. This scenario has clearly known access patterns making option B the best.
Comment: Option A is incorrect because immediately transitioning objects to S3 Glacier Deep Archive would not fulfill the requirement of keeping the most recent 2 years of data highly available and immediately retrievable. Option C is also incorrect because using S3 Intelligent-Tiering with archiving option would not meet the requirement of immediately retrievable data for the most recent 2 years. Option D is not the best choice because transitioning objects to S3 One Zone-Infrequent Access (S3 One Zone-IA) and then to S3 Glacier Deep Archive would not satisfy the requirement of immediately retrievable data for the most recent 2 years. Option B is the correct solution. By setting up an S3 Lifecycle policy to transition objects to S3 Glacier Deep Archive after 2 years, the company can keep all data for at least 25 years while ensuring that data from the most recent 2 years remains highly available and immediately retrievable in the Amazon S3 Standard storage class. This solution optimizes storage costs by leveraging the Glacier Deep Archive for long-term storage.
Comment: this makes sense the question is a bit tricky. I now uderstand that all the data is already kept in S3 Standard meaning immediate retrieval of the most recent data is remains highly available.
Comment: Why not D
Comment: "Data from the most recent 2 years must be highly available and immediately retrievable."
Comment: Additionally, S3 Standard Availability = 99.99% S3 One Zone-IA Availability = 99.5%
Comment: B is the only one possible.
Comment: C would not work as the names of these S3 archives are called Archive Access Tier and Deep Archive access tiers, so since they mention glacier in option C , I think its B which is the correct.
Comment: It's pretty straight forward. S3 Standard answers for High Availaibility/Immediate retrieval for 2 years. S3 Intelligent Tiering would just incur additional cost of analysis while the company insures that it requires immediate retrieval in any moment and without risk to Availability. So a capital B
Comment: C appears to be appropriate - good case for intelligent tiering
Comment: Intelligent tiering appears to be best suited for unknown usage pattern.. but with a known usage pattern Life cycle policy may be optimal.
Comment: The option just says Intelligent Tiering, it doesn't specify when it would transition the date to Deep Archive, so how do we know it would do it at the correct time? It has to be A.
Comment: Max instance store possible at this time is 30TB for NVMe which has the higher I/O compared to EBS. is4gen.8xlarge 4 x 7,500 GB (30 TB) NVMe SSD https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes
Comment: Answer is A While instance store provides fast local storage, it is ephemeral (data is lost when the instance stops or terminates). It's not suitable for workloads that require persistence, like video processing that may span across multiple EC2 instances over time. EBS provides persistent, high-performance storage.
Comment: instance store volume for the root volume, the size of this volume varies by AMI, but the maximum size is 10 GB
Comment: This link shows a max capacity of 30TB, so what is the problem? https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes
Comment: Only the following instance types support an instance store volume as the root device: C3, D2, G2, I2, M3, and R3, and we're using an I3, so an instance store volume is irrelevant.
Comment: THE CORRECT ANSWER IS A. The biggest Instance Store Storage Optimized option (is4gen.8xlarge) has a capacity of only 3TB. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-volumes.html#instance-store-vol-so
Comment: Update: i3en.metal and i3en.24xlarge = 8 x 7500 GB (60TB)
Comment: The correct Answer is A : Amazon EC2 instance store (Instance Store) is usually not the best choice because the storage it provides is temporary and tied to the life cycle of the instance. When an instance is stopped or terminated, data on the instance store is lost. In this scenario, the company's requirements were to have the maximum possible I/O performance and required durable data storage. Therefore, using Amazon EC2 Instance Store does not meet these requirements because it lacks durability. In contrast, Amazon EBS (Elastic Block Store) provides persistent regional block storage and can meet the needs of high-performance I/O. Therefore, the answer should include Amazon EBS, not Amazon EC2 instance storage.
Comment: "The company's requirements were to have the maximum possible I/O performance and required durable data storage." Yeah, but not for the same data. 10 TB "maximum possible I/O performance" for processing (= temporary) 300 TB "very durable" (= S3) 900 TB "for archival" (= Glacier)
Comment: pentium75 is right.
Comment: instance store cannot be durable
Comment: The requirement ist "maximum performance". Instance storage is more performant than EBS, therefor D must be correct.
Comment: Ans A - ideally suits situation since its media, fast access and long-term storage... ": EBS for maximum performance, S3 for durable data storage, and S3 Glacier for archival storage."
Comment: A. EC2 Instance store is used mainly for temp data like caching, memory for computation etc
Comment: A is correct answer. ask for copilot as well
Comment: Amazon EBS io2 Block Express Volumes: For 10 TB of high I/O performance storage. Amazon S3 Standard Storage Class: For 300 TB of durable storage for media content. Amazon S3 Glacier Deep Archive: For 900 TB of archival storage.
Comment: I think it is A, because even D to comply the requirements it is a temporary storage and it is not the best choice.
Comment: https://repost.aws/questions/QUHCySI6otStqGftOFHhHeOQ/saa-c03-question
Comment: Although the EC2 instance store is ephemeral, it provides the highest performance, and there is no demand of a presistant data storage for video processing, the best option for storing media is s3, which is an object storage system.
Comment: Correct Answer: A. Amazon EBS for maximum performance, Amazon S3 for durable data storage, and Amazon S3 Glacier for archival storage Explanation: Amazon EBS for maximum performance: Amazon EBS (Elastic Block Store) provides high-performance block storage for use with Amazon EC2. It is well-suited for workloads requiring high I/O performance, such as video processing. Amazon S3 for durable data storage: Amazon S3 (Simple Storage Service) offers highly durable and scalable object storage. It is ideal for storing large amounts of media content with high durability. Amazon S3 Glacier for archival storage: Amazon S3 Glacier is a low-cost storage service for data archiving and long-term backup. It is perfect for storing archival media that is not frequently accessed but needs to be preserved.
Comment: the correct answer is A, max 10TB storage need per instance (not instances)
Comment: A for sure
Comment: Amazon EBS (Elastic Block Store): Provides high I/O performance suitable for video processing tasks. Amazon S3 (Simple Storage Service): Offers very durable and scalable storage, ideal for storing large amounts of media content. Amazon EFS (Elastic File System): While it provides scalable and durable storage, it is optimized for file-based workloads rather than object storage, which is less suitable for large-scale media storage
Comment: The best option for the given requirements would be: A. Amazon EBS for maximum performance, Amazon S3 for durable data storage, and Amazon S3 Glacier for archival storage. Explanation: Amazon EBS for maximum performance: Amazon Elastic Block Store (EBS) provides high-performance block storage volumes for use with Amazon EC2 instances. This is suitable for the 10 TB of storage with maximum possible I/O performance required for video processing. Amazon S3 for durable data storage: Amazon Simple Storage Service (S3) is highly durable, scalable, and secure object storage. It's suitable for the 300 TB of very durable storage needed for storing media content. Amazon S3 Glacier for archival storage: Amazon S3 Glacier provides secure, durable, and low-cost storage for data archiving and long-term backup. It's ideal for the 900 TB of storage required for archival media that is not in use anymore.
Comment: the answer is D From a maximum I/O perspective, Amazon EBS is significantly better than Amazon EC2 instance store for two main reasons: 1. Underlying Storage Technology: Amazon EBS: Utilizes Solid State Drives (SSDs) and NVMe storage options, offering high-performance IOPS (Input/Output Operations Per Second) and throughput. Amazon EC2 Instance Store: Relies on the local hard disk drives (HDDs) attached to the EC2 instance, which have significantly lower IOPS and throughput compared to SSDs.
Comment: Instance store is more than 10T
Comment: Requirement is "minimizes cost and operational overhead" A is better option than B as EKS add additional cost and operational overhead.
Comment: Using Amazon EKS with managed node groups simplifies container orchestration by reducing the operational overhead of managing the underlying infrastructure and Kubernetes control plane. EKS automatically handles tasks like patching, scaling, and deploying containers across multiple nodes, further reducing operational effort. While Spot Instances in an EC2 Auto Scaling group can reduce costs, it requires more manual management of container orchestration (e.g., deploying, scaling, and managing containers across instances), increasing operational overhead compared to EKS. In the exam its highly recommended to select Managed services Like EKS in this case. My choice is B.
Comment: Really ??? You want more configuration efforts for container workload on EC2, instead of using EKS ::))
Comment: USING SPOT INSTANCES WITH EKS https://ec2spotworkshops.com/using_ec2_spot_instances_with_eks.html
Comment: In my opinion option A) seems to be a reasonable at first because setting up AWS EKS might be seem as an operation overhead comparing to the option of running the containers inside the EC2 using docker just as you we do on your own machines. However, consider installing docker on multiple EC2 instances and manually manage docker instances and images will end up in chaos, so, as a conclusion, the operational cost of setting up AWS EKS will worth the effort.
Comment: Answer is A: Amazon ECS: ECS itself is free, you pay only for Amazon EC2 resources you use. Amazon EKS: The EKS management layer incurs an additional cost of $144 per month per cluster. Advantages of Amazon ECS include: Spot instances: Because containers are immutable, you can run many workloads using Amazon EC2 Spot Instances (which can be shut down with no advance notice) and save 90% on on-demand instance costs.
Comment: Ans A - hint: "stateless" and 'don't care' infrastructure - so Spot and containerisation
Comment: Spot instance is definitely the answer for interruptible process. It's between A and B now. I would reckon Option B requires lesser operational overheads than to maintain own fleet of EC2 servers with containers.
Comment: B is correct
Comment: B for sure
Comment: IMHO, the option **B** is the right one. Breaking down the reasons for it: 1 - Spot is much cheaper than on-demand, which already eliminates C&D for cost related. 2 - Even though we can create a bootstrap script to install docker, managing this can be complicated, especially if any of the applications require more than one instance running.
Comment: Container in ec2 or container on a container platform? B
Comment: run applications in containers -> Container service not EC2 (no operational overhead to config container workload on EC2) Spot instance < On-demand cost
Comment: Does A implicitly means run spot Instance on ECS?
Comment: Spot instances for disruption friendly containers which are also cheaper. EKS allows using spot instances from a managed node group that takes away the EC2 operational overhead. Link: https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-provisioning-and-managing-ec2-spot-instances-in-managed-node-groups/ "Previously, customers had to run Spot Instances as self-managed worker nodes in their EKS clusters. This meant doing some heavy lifting such as building and maintaining configuration for Spot Instances in EC2 Auto Scaling groups, deploying a tool for handling Spot interruptions gracefully, deploying AMI updates, and updating the kubelet version running on their worker nodes. Now, all you need to do is supply a single parameter to indicate that a managed node group should launch Spot Instances, and provide multiple instance types that would be used by the underlying EC2 Auto Scaling group."
Comment: A has less operational overhead
Comment: running containers without container service like EKS introduce huge operational effort
Comment: dude always if you have a service that is meant to be used for a job there is the correct answer, is logic.
Comment: It is a lot of work to manage docker environment on ec2 instance by yourself.
Comment: k8s is not easy solution. there are too many to study about it. You have to know about ingress, storageclass, cni, namesapce, etc... they make burdened to operate.
Comment: reponse A
Comment: I would say A and E since Aurora and Fargate are serverless (less operational overhead).
Comment: There's a difference between Amazon Aurora and Amazon Aurora Serverless
Comment: "Aurora serverless" is still a flavor of Aurora, it's not a different product.
Comment: Ans A,E - -PostgreSQL is compatible with Aurora -Fargate for container service Both services are serverless
Comment: A and E since both Aurora and fargate are serverless.
Comment: PostgreSQL is compatible w/ Aurora Fargate & ECS are also paired with containers A&E
Comment: I would say A and E since Aurora and Fargate are serverless (less operational overhead)
Comment: Requirement is to reduce operational overhead, Amazon Aurora provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication. AWS Fargate is a serverless, pay-as-you-go compute engine that lets you focus on building applications without managing servers.
Comment: The reasons are: Migrating the database to Amazon Aurora provides a high performance, scalable PostgreSQL-compatible database with minimal overhead. Migrating the containerized web app to Fargate removes the need to provision and manage EC2 instances. Fargate auto-scales. Together, Aurora and Fargate reduce operational overhead and complexity for the data and application tiers.
Comment: A is the correct answer because migrating the database to Amazon Aurora reduces operational overhead and offers scalability and automated backups. E is the correct answer because migrating the web application to AWS Fargate with Amazon ECS eliminates the need for infrastructure management, simplifies deployment, and improves resource utilization. B. Migrating the web application to Amazon EC2 instances would not directly address the operational overhead and capacity planning concerns mentioned in the scenario. C. Setting up an Amazon CloudFront distribution improves content delivery but does not directly address the operational overhead or capacity planning limitations. D. Configuring Amazon ElastiCache improves performance but does not directly address the operational overhead or capacity planning challenges mentioned. Therefore, the correct answers are A and E as they address the requirements, while the incorrect answers (B, C, D) do not provide the desired solutions.
Comment: Improve the application's infrastructure = Modernize Infrastructure = Least Operational Overhead = Serverless
Comment: A and E are the best options.
Comment: A and E
Comment: a e..............
Comment: One should that Aurora is not serverless. Aurora serverless and Aurora are 2 Amazon services. I prefer C, however the question does not mention any frontend requirements.
Comment: Yes, go for A and E since thes two ressources are serverless.
Comment: The correct answers are A and E. To improve the application's infrastructure, the solutions architect should migrate the PostgreSQL database to Amazon Aurora and migrate the web application to be hosted on AWS Fargate with Amazon Elastic Container Service (Amazon ECS). Amazon Aurora is a fully managed, scalable, and highly available relational database service that is compatible with PostgreSQL. Migrating the database to Amazon Aurora would reduce the operational overhead of maintaining the database infrastructure and allow the company to focus on building and scaling the application. AWS Fargate is a fully managed container orchestration service that enables users to run containers without the need to manage the underlying EC2 instances. By using AWS Fargate with Amazon Elastic Container Service (Amazon ECS), the solutions architect can improve the scalability and efficiency of the web application and reduce the operational overhead of maintaining the underlying infrastructure.
Comment: A and E are obvious choices.
Comment: Option A and E
Comment: The correct answer is B. To maintain the desired performance across all instances in the Amazon EC2 Auto Scaling group, the solutions architect should use a target tracking policy to dynamically scale the Auto Scaling group. A target tracking policy allows the Auto Scaling group to automatically adjust the number of EC2 instances in the group based on a target value for a metric. In this case, the target value for the CPU utilization metric could be set to 40% to maintain the desired performance of the application. The Auto Scaling group would then automatically scale the number of instances up or down as needed to maintain the target value for the metric. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html
Comment: target tracking policy = maintain
Comment: B is the correct answer, since target scaling monitors cloudwatch metrics, while simple/step scaling monitors cloudwatch alarms.
Comment: Useful, jaradat02. Thanks.
Comment: 40% CPU for best performance is a "target tracking" policy for scaling so B is correct. A: Wrong policy CD: Won't achieve 40% CPU
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html
Comment: I really don't get what kind of software running like a car with the most economical fuel speed range, but well, the answer is B
Comment: The application performs best when the CPU utilization of the EC2 instances is at or near 40%. Target tracking will maintain CPU utilization at 40%. When CloudWatch detects that the average CPU utilization is beyond 40%, it will trigger the target tracking policy to scale out the auto scaling group to meet this target utilization. Once everything is settled and the average CPU utilization has gone below 40%, another scale in action will kick in and reduce the number of auto scaling instances in the auto scaling group.
Comment: The key reasons are: A target tracking policy allows defining a specific target metric value to maintain, in this case 40% CPU utilization. Auto Scaling will automatically add or remove instances to keep utilization at the target level, without manual intervention. This will dynamically scale the group to maintain performance as load changes. A simple scaling policy only responds to breaching thresholds, not maintaining a target. Scheduled actions and Lambda would require manual calculation and updates to track utilization. Target tracking policies are the native Auto Scaling feature designed to maintain a metric at a target value.
Comment: Target tracking policy is the most appropriate choice. This policy allows ASG to automatically adjust the desired capacity based on a target metric, such as CPU utilization. By setting the target metric to 40%, ASG will scale the number of instances up or down as needed to maintain the desired CPU utilization level. This ensures that the application's performance remains optimal. A suggests using a simple scaling policy, which allows for scaling based on a fixed metric or threshold. However, it may not be as effective as a target tracking policy in dynamically adjusting the capacity to maintain a specific CPU utilization level. C suggests using an Lambda to update the desired capacity. While this can be done programmatically, it would require custom scripting and may not provide the same level of automation and responsiveness as a target tracking policy. D suggests using scheduled scaling actions to scale up and down ASG at predefined times. This approach is not suitable for maintaining the desired performance in real-time based on actual CPU utilization.
Comment: B of course.
Comment: B seem to the correct response. With a target tracking scaling policy, you can increase or decrease the current capacity of the group based on a target value for a specific metric. This policy will help resolve the over-provisioning of your resources. The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value. In addition to keeping the metric close to the target value, a target tracking scaling policy also adjusts to changes in the metric due to a changing load pattern.
Comment: target tracking - CPU at 40%
Comment: Option B
Comment: B is correct
Comment: Option B. Target tracking policy. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html
Comment: B CPU utilization = target tracking
Comment: B is the answer
Comment: I want to restrict access to my Amazon Simple Storage Service (Amazon S3) bucket so that objects can be accessed only through my Amazon CloudFront distribution. How can I do that? Create a CloudFront origin access identity (OAI) https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-access-to-amazon-s3/
Comment: Thanks it convinces me
Comment: The key reasons are: An OAI provides secure access between CloudFront and S3 without exposing the S3 bucket publicly. The OAI is associated with the CloudFront distribution. The S3 bucket policy limits access only to that OAI. This ensures only CloudFront can access the objects, not direct S3 access. Option A is complex to manage individual bucket policies. Option B exposes credentials that aren't needed. Option C works but OAI is the preferred method. So using an origin access identity provides the most secure way to serve private S3 content through CloudFront. The OAI prevents direct public access to the S3 bucket.
Comment: C would also work but missing important details in the answer D is legacy and architect should not recommend it
Comment: "If your users try to access objects using Amazon S3 URLs, they're denied access. The origin access identity has permission to access objects in your Amazon S3 bucket, but users don't." https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
Comment: To meet the requirements of serving files through CloudFront while restricting direct access to the S3 bucket URL, the recommended approach is to use an origin access identity (OAI). By creating an OAI and assigning it to the CloudFront distribution, you can control access to the S3 bucket. This setup ensures that the files stored in the S3 bucket are only accessible through CloudFront and not directly through the S3 bucket URL. Requests made directly to the S3 URL will be blocked. Option A suggests writing individual policies for each S3 bucket, which can be cumbersome and difficult to manage, especially if there are multiple buckets involved. Option B suggests creating an IAM user and assigning it to CloudFront, but this does not address restricting direct access to the S3 bucket URL. Option C suggests writing an S3 bucket policy with CloudFront distribution ID as the Principal, but this alone does not provide the necessary restrictions to prevent direct access to the S3 bucket URL.
Comment: DECEMBER 2022 UPDATE: Restricting access to an Amazon S3 origin: CloudFront provides two ways to send authenticated requests to an Amazon S3 origin: origin access control (OAC) and origin access identity (OAI). We recommend using OAC because it supports: All Amazon S3 buckets in all AWS Regions, including opt-in Regions launched after December 2022 Amazon S3 server-side encryption with AWS KMS (SSE-KMS) Dynamic requests (PUT and DELETE) to Amazon S3 OAI doesn't work for the scenarios in the preceding list, or it requires extra workarounds in those scenarios. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
Comment: The correct answer is D. To meet the requirements, the solutions architect should create an origin access identity (OAI) and assign it to the CloudFront distribution. The S3 bucket permissions should be configured so that only the OAI has read permission. An OAI is a special CloudFront user that is associated with a CloudFront distribution and is used to give CloudFront access to the files in an S3 bucket. By using an OAI, the company can serve the files through the CloudFront distribution while preventing direct access to the S3 bucket. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
Comment: D is the right answer
Comment: D is correct but instead of OAI using OAC would be better since OAI is legacy
Comment: Thanks, I didn't know about OAC.
Comment: D is correct
Comment: Historical reports = Static content = S3
Comment: A is the correct answer The solution should be cost-effective, limit the provisioning of infrastructure resources, and provide the fastest possible response time.
Comment: Ans A - S3 is designed to optimise costs, highly scalable and can store static content such as website. CloudFront is designed to securely deliver content with low latency and high transfer rate.
Comment: Historical data will not change, and hence they are static content. So the answer is S3 with distributed content (Cloudfront)
Comment: A is the most suitable choice because the content is static and downloadable
Comment: A. S3 is designed to optimize storage costs, is highly scalable and can hold static content e.g. a website. CloudFront is designed to securely deliver content with low latency and high transfer speeds.
Comment: Bringing content closer to users, Answer is A
Comment: Global, cost-effective, serverless, low latency = CloudFront with S3 Static content = S3
Comment: Historical reports = Static content = S3
Comment: By using CloudFront, the website can leverage the global network of edge locations to cache and deliver the performance reports to users from the nearest edge location, reducing latency and providing fast response times. Amazon S3 serves as the origin for the files, where the reports are stored. Option B is incorrect because AWS Lambda and Amazon DynamoDB are not the most suitable services for serving downloadable files and meeting the website demands globally. Option C is incorrect because using an Application Load Balancer with Amazon EC2 Auto Scaling may require more infrastructure provisioning and management compared to the CloudFront and S3 combination. Additionally, it may not provide the same level of global scalability and fast response times as CloudFront. Option D is incorrect because while Amazon Route 53 is a global DNS service, it alone does not provide the caching and content delivery capabilities required for serving the downloadable reports. Internal Application Load Balancers do not address the global scalability and caching requirements specified in the scenario.
Comment: Very good explanations!
Comment: The correct answer is Option A. To meet the requirements, the solutions architect should recommend using Amazon CloudFront and Amazon S3. By combining Amazon CloudFront and Amazon S3, the solutions architect can provide a scalable and cost-effective solution that limits the provisioning of infrastructure resources and provides the fastest possible response time. https://aws.amazon.com/cloudfront/ https://aws.amazon.com/s3/
Comment: A is correct
Comment: A is the best and most cost effective option if only download of the static pre-created report(no data processing before downloading) is a requirement.
Comment: A is correct
Comment: https://www.examtopics.com/discussions/amazon/view/27935-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: https://www.examtopics.com/discussions/amazon/view/27935-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: See this discussion: https://www.examtopics.com/discussions/amazon/view/27935-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Option C since RDS Custom has access to the underlying OS and it provides less operational overhead. Also, a read replica in another Region can be used for DR activities. https://aws.amazon.com/blogs/database/implementing-a-disaster-recovery-strategy-with-amazon-rds/
Comment: You can't create cross-Region replicas in RDS Custom for Oracle: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html#custom-rr.limitations
Comment: It should be C: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-custom.html and https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-custom-oracle.html
Comment: how it is C when the read replica is not meant for DR
Comment: If the source DB instance fails, you can promote your Read Replica to a standalone source server.
Comment: Ans D - use regular RDS Oracle; no need for RDS Custom because the question doesn't state and special customisations... the only bit unanswered is "...maintain access to company's underlying o/s"
Comment: Option C provides the right balance of managed service convenience, access to the underlying OS, and effective disaster recovery with cross-region read replicas
Comment: "You can't create cross-Region RDS Custom for Oracle replicas." So it can't be C. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html B and D don't provide access to underlying OS. So the only option left is A, which won't help minimize the operational overhead though.
Comment: B, D - do not have access to underlying OS. Both A and C could work, but C is less Overhead. C - Amazon RDS Custom for Oracle actually supports creating read replicas. "Creating an RDS Custom for Oracle replica is similar to creating an RDS for Oracle replica, but with important differences." (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html). The read replica is not meant for disaster recovery, but it could work as such when no better options are available.
Comment: "You can't create cross-Region RDS Custom for Oracle replicas." https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html
Comment: You can't create cross-Region RDS Custom for Oracle replicas.
Comment: Since we need to have access to the underlying infrastructure, C makes sense.
Comment: Its C Key : Access to underlying O.S - RDS custom can give you this feature General RDS for Oracle( or any) - you can't access underlying O.S So, definitely C considering this point in the question
Comment: Defintely not C. You cannot create a read replica of RDS custom for Oracle in a different region: https://aws.amazon.com/blogs/database/build-high-availability-for-amazon-rds-custom-for-oracle-using-read-replicas/
Comment: C for sure
Comment: Answer C is not correct as cross-Region replicas in RDS Custom for Oracle are not allowed as stated by a previous answe. Correct answer: B https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html Low operational overhead since the backup is automated.
Comment: B doesnt give you access to the underlying OS
Comment: RDS Custom
Comment: C. Migrate the Oracle database to Amazon RDS Custom for Oracle. Create a read replica for the database in another AWS Region. Explanation: Amazon RDS Custom for Oracle: Amazon RDS Custom for Oracle allows the company to run Oracle databases on managed instances in the AWS Cloud. It provides managed services for tasks such as backups, patching, and monitoring, minimizing operational overhead for normal operations. Read Replica in Another AWS Region: By creating a read replica for the database in another AWS Region, the company can set up disaster recovery (DR) with minimal operational overhead. Amazon RDS automatically handles replication between the primary database and the read replica, ensuring data consistency and minimizing management tasks for DR setup.
Comment: A. Migrate the Oracle database to an Amazon EC2 instance. Set up database replication to a different AWS Region. Explanation: Migrating the Oracle database to an Amazon EC2 instance allows the company to maintain full control over the database, including access to the underlying operating system. Setting up database replication to a different AWS Region ensures disaster recovery with minimal operational overhead.
Comment: Has to be C, since they need access to the OS: “ require access to the underlying OS and DB environment” https://aws.amazon.com/about-aws/whats-new/2021/10/amazon-rds-custom-oracle/
Comment: "The company also needs to maintain access to the database's underlying operating system"
Comment: (A) goes too far with EC2, increasing operational overhead for normal operations. (C) with RDS Custom for Oracle is better. see f761d0e post for link.
Comment: SSE-KMS vs SSE-S3 - The last seems to have less overhead (as the keys are automatically generated by S3 and applied on data at upload, and don't require further actions. KMS provides more flexibility, but in turn involves a different service, which finally is more "complex" than just managing one (S3). So A and B are excluded. If you are in doubt, you are having 2 buckets in A and B, while just keeping one in C and D. https://s3browser.com/server-side-encryption-types.aspx Decide between C and D is deciding on Athena or RDS. RDS is a relational db, and we have documents on S3, which is the use case for Athena. Athena is also serverless, which eliminates the need of controlling the underlying infrastructure and capacity. So C is the answer. https://aws.amazon.com/athena/
Comment: See comment from Nicknameinvalid below. You get your answer.
Comment: It'a since replication works for new objects but not for the existing ones, untless you use batch replication which is not the case.
Comment: Answer A has you move the data before you enable replication, therefore there is no difference between A and C when it comes to the point in time you enable replication. I agree A would be a better choice if the order of operations said, create a bucket->Enable encryption->move files...but it doesn't. It has you create the bucket and move the files.
Comment: Answer is A: Amazon S3 Bucket Keys reduce the cost of Amazon S3 server-side encryption using AWS Key Management Service (SSE-KMS). This new bucket-level key for SSE can reduce AWS KMS request costs by up to 99 percent by decreasing the request traffic from Amazon S3 to AWS KMS. With a few clicks in the AWS Management Console, and without any changes to your client applications, you can configure your bucket to use an S3 Bucket Key for AWS KMS-based encryption on new objects. The Existing S3 bucket might have uncrypted data - encryption will apply new data received after the applying of encryption on the new bucket.
Comment: But in server side encryption Multi Region Keys is not possible which leaves to Option C
Comment: "you manage the multi-Region key in each Region independently. Neither AWS nor AWS KMS ever automatically creates or replicates multi-Region keys into any Region on your behalf. AWS managed keys, the KMS keys that AWS services create in your account for you, are always single-Region keys." https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html
Comment: from your link you missed this part: you can encrypt data in one AWS Region and decrypt it in a different AWS Region without re-encrypting or making a cross-Region call to AWS KMS
Comment: Don't know what "kays" are, could they be a trap?
Comment: Kays = keys, mistype i think.
Comment: Cost reduction is in comparison bet Bucket level KMS key and object level KMS key. Not between SSE-KMS and SSE-S3. Hence its a wrong comparison
Comment: Reducing cost was never the target, it's LEAST operational. In that regard SSE-S3 AWS fully managed.
Comment: RDS is relational DB so we need Athena for this
Comment: I think A is correct because SSE-S3 doesn't support multi-region key management, but SSE-KMS has.
Comment: Ans A - once you realise "SL" is a typo for "ML" then its only the Athena options, and in the case of option it means setting up a new S3 bucket
Comment: "Unencrypted objects and objects encrypted with SSE-S3 are replicated by default." (stephane maarek course)
Comment: gpt-4 says A
Comment: C for sure
Comment: Since S3 has provides the automatic encryption for the storage objects, create another bucket is redundant, C has the least operational overhead.
Comment: What do mean by 'load the data into the existing bucket' ! the data is already staying in the existing bucket !
Comment: The question says 'existing and new data'
Comment: from @pentium75 Data in S3 is queried with Athena, not RDS, thus B and D are out. A requires a new bucket and loading data into that - Why, since data is already in S3? It says to enable CRR only after loading the data, so existing data won't be replicated anyway. C uses existing data (less operational overhead compared to loading data into a new bucket) and SSE-E3 (less operational overhead than SSE-KMS).
Comment: Option B suggests using Amazon RDS to query the data, which introduces additional complexity compared to using Amazon Athena. Option C suggests using server-side encryption with Amazon S3 managed encryption keys (SSE-S3) instead of AWS KMS multi-Region keys, which might not meet the encryption requirements. Option D also suggests using Amazon RDS to query the data, which, as mentioned earlier, is not the best choice for a serverless solution and would result in higher operational overhead.
Comment: The answer is A because SSE-S3 does not support cross-region replication of encrypted data. If you perform cross-region replication, you will have to re-encrypt the data.
Comment: awai it is correct
Comment: As per Amazon Q: The easiest way to encrypt existing objects in S3 is to use server-side encryption with S3-managed keys (SSE-S3). Here are the basic steps: 1. Enable SSE-S3 on the target S3 bucket if it is not already enabled. This will ensure all new or copied objects are encrypted automatically. 2. Create an S3 inventory report for the source bucket containing the objects. This will generate a CSV file with metadata of all objects. 3. Use S3 Select or AWS Athena to query the inventory report and filter for only unencrypted objects. 4. Create an S3 Batch Operations job to copy the filtered unencrypted objects to the target bucket. The copy operation will automatically encrypt the objects using the bucket's SSE-S3 configuration.
Comment: 5. Monitor the job completion to ensure all objects were encrypted. You can optionally delete the original unencrypted versions after verifying successful encryption. This approach minimizes disruption and performs the encryption without having to rewrite existing data or code. Also Refer: https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops-copy-example-bucket-key.html
Comment: Data in S3 is queried with Athena, not RDS, thus B and D are out. A requires a new bucket and loading data into that - Why, since data is already in S3? It says to enable CRR only after loading the data, so existing data won't be replicated anyway. C uses existing data (less operational overhead compared to loading data into a new bucket) and SSE-E3 (less operational overhead than SSE-KMS).
Comment: Most clear explanation. Thanks!
Comment: I selected A because SSE-S3 keys are not multi-regional keys. You must use SSE-KMS for the multi-regional keys and then for serverless its Aurora.
Comment: It says "data requires encryption", not that it must use same key in both regions.
Comment: **AWS PrivateLink provides private connectivity between VPCs, AWS services, and your on-premises networks, without exposing your traffic to the public internet**. AWS PrivateLink makes it easy to connect services across different accounts and VPCs to significantly simplify your network architecture. Interface **VPC endpoints**, powered by AWS PrivateLink, connect you to services hosted by AWS Partners and supported solutions available in AWS Marketplace. https://aws.amazon.com/privatelink/
Comment: The solution that meets these requirements best is option D. By asking the provider to create a VPC endpoint for the target service, the company can use AWS PrivateLink to connect to the target service. This enables the company to access the service privately and securely over an Amazon VPC endpoint, without requiring a NAT gateway, VPN, or AWS Direct Connect. Additionally, this will restrict the connectivity only to the target service, as required by the company's security team. Option A VPC peering connection may not meet security requirement as it can allow communication between all resources in both VPCs. Option B, asking the provider to create a virtual private gateway in its VPC and use AWS PrivateLink to connect to the target service is not the optimal solution because it may require the provider to make changes and also you may face security issues. Option C, creating a NAT gateway in a public subnet of the company's VPC can expose the target service to the internet, which would not meet the security requirements.
Comment: Ans D - create a unique, private only link: "Ask the provider to create a VPC endpoint for the target service. Use AWS PrivateLink to connect to the target service"
Comment: no split decisions on this answer eh? not like the last one. lol
Comment: AWS PrivateLink / VPC Endpoint Services: • Connect services privately from your service VPC to customers VPC • Doesn't need VPC Peering, public Internet, NAT Gateway, Route Tables • Must be used with Network Load Balancer & ENI
Comment: option D is correct
Comment: The best solution to meet the requirements is option D: Ask the provider to create a VPC endpoint for the target service Use AWS PrivateLink to connect to the target service The reasons are: PrivateLink provides private connectivity between VPCs without using public internet. The provider creates a VPC endpoint in their VPC for the target service. The company uses PrivateLink to securely access the endpoint from their VPC. Connectivity is restricted only to the target service. The connection is initiated only from the company's VPC. Options A, B, C would expose the connection to the public internet or require infrastructure changes in the provider's VPC. PrivateLink enables private, restricted connectivity to the target service without VPC peering or public exposure.
Comment: Option C meets the requirements of establishing a private and restricted connection to the service hosted in the provider's VPC. By asking the provider to create a VPC endpoint for the target service, you can establish a direct and private connection from your company's VPC to the target service. AWS PrivateLink ensures that the connectivity remains within the AWS network and does not require internet access. This ensures both privacy and restriction to the target service, as the connection can only be initiated from your company's VPC. A. VPC peering does not restrict access only to the target service. B. PrivateLink is typically used for accessing AWS services, not external services in a provider's VPC. C. NAT gateway does not provide a private and restricted connection to the target service. Option D is the correct choice as it uses AWS PrivateLink and VPC endpoint to establish a private and restricted connection from the company's VPC to the target service in the provider's VPC.
Comment: VPC Endpoint (Target Service) - for specific services (not accessing whole vpc) VPC Peering - (accessing whole VPC)
Comment: VPC Peering Connection: All resources in a VPC, such as ECSs and load balancers, can be accessed. VPC Endpoint: Allows access to a specific service or application. Only the ECSs and load balancers in the VPC for which VPC endpoint services are created can be accessed.
Comment: Option D, but seems that it is vise versa. Customer needs to create Privatelink and and you VPC endpoint to connect to Privatelink
Comment: AWS PrivateLink / VPC Endpoint Services: • Connect services privately from your service VPC to customers VPC • Doesn't need VPC Peering, public Internet, NAT Gateway, Route Tables • Must be used with Network Load Balancer & ENI
Comment: D. Here you are the one initiating the connection
Comment: PrivateLink is a more generalized technology for linking VPCs to other services. This can include multiple potential endpoints: AWS services, such as Lambda or EC2; Services hosted in other VPCs; Application endpoints hosted on-premises. https://www.tinystacks.com/blog-post/aws-vpc-peering-vs-privatelink-which-to-use-and-when/
Comment: While VPC peering enables you to privately connect VPCs, AWS PrivateLink enables you to configure applications or services in VPCs as endpoints that your VPC peering connections can connect to.
Comment: The solution that meets these requirements is Option D: * Ask the provider to create a VPC endpoint for the target service. * Use AWS PrivateLink to connect to the target service. Option D involves asking the provider to create a VPC endpoint for the target service, which is a private connection to the service that is hosted in the provider's VPC. This ensures that the connection is private and restricted to the target service, as required by the company's security team. The company can then use AWS PrivateLink to connect to the target service over the VPC endpoint. AWS PrivateLink is a fully managed service that enables you to privately access services hosted on AWS, on-premises, or in other VPCs. It provides secure and private connectivity to services by using private IP addresses, which ensures that traffic stays within the Amazon network and does not traverse the public internet. Therefore, Option D is the solution that meets the requirements.
Comment: AWS PrivateLink documentation: https://docs.aws.amazon.com/privatelink/latest/userguide/what-is-privatelink.html
Comment: D is right,if requirement was to be ok with public internet then option C was ok.
Comment: AWS Database Migration Service (AWS DMS) helps you migrate databases to AWS quickly and securely. The source database remains fully operational during the migration, minimizing downtime to applications that rely on the database. ... With AWS Database Migration Service, you can also continuously replicate data with low latency from any supported source to any supported target. https://aws.amazon.com/dms/
Comment: PostgreSQL -> Aurora PostgreSQL requires schema conversion per https://aws.amazon.com/dms/schema-conversion-tool/
Comment: SCT is compatible with PostgreSQL as source and Aurora PostgreSQL as destination, but not required.
Comment: AC, here it is clearly shown https://docs.aws.amazon.com/zh_cn/dms/latest/sbs/chap-manageddatabases.postgresql-rds-postgresql.html
Comment: You nailed it !
Comment: Ans C, E - C: AWS Database Migration Service to migrate databases to AWS, source database remains fully operational during the migration, avoiding application downtime. https://aws.amazon.com/dms/ E: monitor with CloudWatch As for C - not convinced: its PostgreSQL to PostgreSQL migration... no SCT is needed?
Comment: No, since you're using the same schema for Postgresql.
Comment: A and c obviously
Comment: AC is more accurate as DMS will help to migrate the on-premises data base to cloud with ease and for ongoing replication to synchronized the datbase "ongiong replication task" will be helpfull. And yes its PostgreSQL to PostgreSQL migration so no SCT is needed ehre
Comment: WeLL CHATGPT says SCT is not required so , AC makes sense
Comment: Keywords: - migrating its on-premises PostgreSQL database to Amazon Aurora PostgreSQL - The Aurora database must remain synchronized with the on-premises database Analysis: Option A satisfy the requirement of “synchronized with the on-premises database” Option C suits for the homogeneous database migration. Option D is not needed in this scenario, it suits for the heterogeneous database. Homogeneous database migration tools: https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/homogeneous-migration-tools.html Heterogeneous database migration tools: https://aws.amazon.com/dms/schema-conversion-tool/
Comment: CD: Migrating a schema from PostgreSQL to Amazon Aurora (PostgreSQL) usually requires using the AWS Schema Conversion Tool (SCT) and the AWS Database Migration Service (DMS)
Comment: To meet the requirements of migrating an on-premises PostgreSQL database to Amazon Aurora PostgreSQL while keeping the on-premises database online and ensuring synchronization with the Aurora database, the following actions need to be taken: Create an ongoing replication task (Option A): This action involves setting up continuous replication between the on-premises PostgreSQL database and the Aurora PostgreSQL database. This ensures that changes made to the on-premises database are replicated to the Aurora database in real-time, keeping them synchronized. Create an AWS Database Migration Service (AWS DMS) replication server (Option C): AWS DMS provides a reliable and efficient way to migrate databases to AWS while minimizing downtime. By creating an AWS DMS replication server, you can configure and manage the replication tasks between the on-premises database and the Aurora database.
Comment: answer is CD : postgresql and aurora postgresql have different schemes, you need sct for conversion and dms for the migration (replication)
Comment: AC perform ongoing replication using AWS DMS to keep the source and target databases in sync
Comment: DMS has Continuous Data Replication using CDC
Comment: CD A is out because it does not specify what is the service to perform the replication task, clearly what needed here is DMS B is out because backup is solution to keep 2 DB in sync, backup and restore takes long time C is correct as DMS takes care both full load and ongoing replication, see this youtube video https://www.youtube.com/watch?v=VhXDa9SPDLw D is right as from to PostgreSQL to Amazon Aurora PostgreSQL you need AWS Schema Conversion Tool, see https://aws.amazon.com/dms/schema-conversion-tool/ E is out monitor itself doen't perform the replication work, if we have to choose 3 options then we can have E selected
Comment: https://docs.aws.amazon.com/zh_cn/dms/latest/sbs/chap-manageddatabases.postgresql-rds-postgresql-ongoing-replication.html literally says that you must "configure the ongoing replication task"
Comment: Well technically when you operate such task, you must create a database on the cloud, then operate a migration using DMS and none of the propositions give you those two tasks separately. Sometimes those questions can be really frustrating.
Comment: C. Create an AWS Database Migration Service (AWS DMS) replication server. E. Create an Amazon EventBridge (Amazon CloudWatch Events) rule to monitor the database synchronization. AWS DMS can replicate data from on-premises databases to Aurora PostgreSQL in real time, so the on-premises database will remain online and accessible during the migration. AWS DMS can also automatically convert the database schema, so there is no need to use AWS SCT. An Amazon EventBridge rule can be used to monitor the database synchronization and send notifications if any errors occur. This is important because it allows the solutions architect to quickly identify and resolve any issues that may arise during the migration. A database backup of the on-premises database is not necessary because AWS DMS will replicate the data in real time. Creating an ongoing replication task is not necessary because AWS DMS will automatically create an ongoing replication task when the replication server is created.
Comment: Mate you can monitor everything you want but it is not going to make sure the synchronization is working, an alert is not going to help.
Comment: Create an AWS Database Migration Service (AWS DMS) replication server then create an ongoing replication task
Comment: A) Create an ongoing replication task C) Create an AWS Database Migration Service (AWS DMS) replication server The key reasons are: An ongoing DMS replication task keeps the source and target databases synchronized during the migration. The DMS replication server manages and executes the replication tasks. Together, these will continuously replicate changes from on-prem to Aurora to keep them in sync. A database backup alone wouldn't maintain synchronization.
Comment: Use a group email address for the management account's root user https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html#best-practices_mgmt-acct_email-address
Comment: Option B ensures that all future notifications are not missed by configuring the AWS account root user email addresses as distribution lists that are monitored by a few administrators. By setting up alternate contacts in the AWS Organizations console or programmatically, the notifications can be sent to the appropriate administrators responsible for monitoring and responding to alerts. This solution allows for centralized management of notifications and ensures they are limited to account administrators. A. Floods all users with notifications, lacks granularity. C. Manual forwarding introduces delays, centralizes responsibility. D. No flexibility for specific account administrators, limits customization.
Comment: Ans B - as opposed to option D, because the organisation account structure implies there is more than one root account: "The root email recipient missed a notification that was sent to the root user email address of one account."
Comment: "Use a group email address for root user credentials: Use an email address that is managed by your business and forwards received messages directly to a group of users. If AWS must contact the owner of the account, this approach reduces the risk of delays in responding, even if individuals are on vacation, out sick, or have left the business. The email address used for the root user should not be used for other purposes." https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html#ru-bp-group
Comment: Lol.. How is this AWS related question. Isnt it general knowledge.
Comment: No idea why "D" would be correct answer unless there is some missing context in the question or the answer. "B" is best practice as pointed out in other links.
Comment: the only answer with sense is "B", because "A" is not exclusive, "C" is exactly the case the want to avoid, and "D" just don't make sense
Comment: distribution list is the way to go
Comment: The reasons are: Alternate contacts allow defining other users to receive root emails. Distribution lists ensure multiple admins get notified. Limits notifications to account admins rather than all users. Using the same root email address for all accounts (Option D) is not recommended. Relying on one admin or external forwarding (Options A, C) introduces delays or single points of failure.
Comment: all admins need access or else some wont get the right mails and cant do their job, sending it only to a few would disrupt the workflowso it is D
Comment: From the links provided below there are no mention of having a distribution list capability within AWS: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html#best-practices_mgmt-acct_email-address As per link for best practices: Use a group email address for the management account's root user!
Comment: The clue is in the pudding!! Question: account "administrators" Answer: Configure all AWS account root user email addresses as distribution lists that go to a few "administrators"
Comment: Option A: wrong - sends email to everybody Option B: correct (but sub-optimal because distribution lists aren't all that secure) Option C: wrong - single point of failure on the new administrator Option D: wrong - each root email address must be unique, you can't change them all to the same one
Comment: The more aligned answer to this article: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html#best-practices_mgmt-acct_email-address is B. D would be best if it'd said that the email you configure as "root user email address" will be a distribution list. The phrase "all future notifications are not missed" points to D, cos' it said: ".. and all newly created accounts to use the same root user email address" so the future account that will be created will be covered with the business policy. It's not 100% clear, but I'll choose B.
Comment: Una pregunta si la gente va votando las preguntas por que los administradores no cambian la respuesta correcta. Es a interpretación y ya?
Comment: El administrador de "examtopics" pasa olímpicamente de marcar la respuesta correcta y es evidente que muchas respuestas que indica como "correctas" no lo son. Dice muy poco del servicio que dan.
Comment: Using the method of crossing out the option that does not fit.... Option A: address to all users of organization (wrong) Option B: go to a few administration who can respond to alerts (question says to send notification to administrators not a selected few ) Option C: send to one administrator and giving him responsibility (wrong) Option D: correct (as this is the one option left after checking all others).
Comment: Option B does not meet the requirements because it would require configuring all AWS account root user email addresses as distribution lists, which is not necessary to meet the requirements.
Comment: Migrating to Amazon MQ reduces the overhead on the queue management. C and D are dismissed. Deciding between A and B means deciding to go for an AutoScaling group for EC2 or an RDS for Postgress (both multi- AZ). The RDS option has less operational impact, as provide as a service the tools and software required. Consider for instance, the effort to add an additional node like a read replica, to the DB. https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/active-standby-broker-deployment.html https://aws.amazon.com/rds/postgresql/
Comment: This also helps anyone in doubt; https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/active-standby-broker-deployment.html
Comment: Yes but active/standby is fault tolerance, not HA. I would concede after thinking about it that B is probably the answer that will be marked correct but its not a great question.
Comment: To meet the requirements of providing the highest availability with the least operational overhead, the solutions architect should take the following actions: * By migrating the queue to Amazon MQ, the architect can take advantage of the built-in high availability and failover capabilities of the service, which will help ensure that messages are delivered reliably and without interruption. * By creating a Multi-AZ Auto Scaling group for the EC2 instances that host the application, the architect can ensure that the application is highly available and able to handle increased traffic without the need for manual intervention. * By migrating the database to a Multi-AZ deployment of Amazon RDS for PostgreSQL, the architect can take advantage of the built-in high availability and failover capabilities of the service, which will help ensure that the database is always available and able to handle increased traffic. Therefore, the correct answer is Option B.
Comment: B is the correct answer
Comment: CD, you cannot have EC2 scaling work with RabbitMQ as only once instance can be active A: Is good but B is better B: Correct due to usage of RDS for PG so less overhead
Comment: Agree with B
Comment: B offers high availability and low operational overheads.
Comment: Option B is the best solution to meet the high availability and low overhead requirements: Migrate the queue to redundant Amazon MQ Use Auto Scaling groups across AZs for the application Migrate the database to Multi-AZ RDS PostgreSQL The reasons are: Amazon MQ provides a managed, highly available RabbitMQ cluster Multi-AZ Auto Scaling distributes the application across AZs RDS PostgreSQL is managed, multi-AZ capable database Together this architecture removes single points of failure RDS and MQ reduce operational overhead over self-managed
Comment: B least operational overhead (Amazon RDS for PostgreSQL --> hence AD out / C says EC2 so out --> Hence B)
Comment: Option B provides the highest availability with the least operational overhead. By migrating the queue to a redundant pair of RabbitMQ instances on Amazon MQ, the messaging system becomes highly available. Creating a Multi-AZ Auto Scaling group for EC2 instances hosting the application ensures that it can automatically scale and maintain availability across multiple Availability Zones. Migrating the database to a Multi-AZ deployment of Amazon RDS for PostgreSQL provides automatic failover and data replication across multiple Availability Zones, enhancing availability and reducing operational overhead. A. Incorrect because it does not address the high availability requirement for the RabbitMQ queue and the PostgreSQL database. C. Incorrect because it does not provide redundancy for the RabbitMQ queue and does not address the high availability requirement for the PostgreSQL database. D. Incorrect because it does not address the high availability requirement for the RabbitMQ queue and does not provide redundancy for the application instances.
Comment: B for me.
Comment: B is right all explanations below are correct
Comment: Option B is right answer
Comment: B for me
Comment: i go for D here A and B says you are copying the file to another bucket using lambda, C an D just uses S3 replication to copy the files, They are doing exactly the same thing while C and D do not require setting up of lambda, which should be more efficient The question says the team is manually copying the files, automatically replicating the files should be the most efficient method vs manually copying or copying with lambda.
Comment: S3 Replication: Configuring S3 replication between the initial and analysis S3 buckets automates the process of moving files between the buckets without the need to manually copy files or run a Lambda function for this purpose. This reduces operational overhead. S3 Event Notifications: Once files are replicated to the analysis bucket, you can configure S3 event notifications for the s3:ObjectCreated event. This event triggers actions (such as invoking Lambda functions and sending data to SageMaker Pipelines) when new files are placed in the analysis bucket. The answer is C
Comment: yes d because of least operational overhead and also s3 event notification can only send to sns.sqs.and lambda , not to sagemaker.eventbridge can send to sagemaker
Comment: but the reporting team also wants to use AWS Lambda functions to run pattern-matching code on the copied , S3 replication cons is copying everything
Comment: The Lambda functions should run "on the copied data", so first copy, THEN run Lambda function, which is achieved by D.
Comment: C and D aren't answers as replicating the S3 bucket isn't efficient, as other teams are starting to use it to store larger docs not related to the reporting, making replication not useful. As Amazon SageMaker Pipelines, ..., is now supported as a target for routing events in Amazon EventBridge, means the answer is B https://aws.amazon.com/about-aws/whats-new/2021/04/new-options-trigger-amazon-sagemaker-pipeline-executions/
Comment: I think you are mis-interpreting the question. I think you need to use all files, including the ones provided by other teams, otherwise how can you tell what files to copy? I think the point of this statement is to show that more files are in use, and being copied at different times, rather than suggesting you need to differentiate between the two sources of files.
Comment: Not sure how far lambda will cope up with larger files with the timelimit in place.
Comment: "The reporting team wants to move the files automatically to analysis S3 bucket as the files enter the initial S3 bucket." Replication is asynchronous, with lambda the data will be available faster. So I think A is the answer.
Comment: but B is not least operational overhead , D is least operational overhead
Comment: You misinterpret it ... the reporting team is overload, cos' more teams request their services uploading more data to the bucket. That's the reason reporting team need to automate the process. So ALL the bucket objects need to be copied to other bucket, and the replication is better an cheaper than use Lambda. So the answer is D.
Comment: Ans D - least operational overhead using replication; I was initially going for Ans C until I spotted S3 event notification can only send to SQS, SNS, Lambda - not directly to Sagemaker; but Eventbridge can send to Sagemaker. Not sure why author prefers A...?
Comment: S3 event can't be use to notify sagemaker, So C can't be right option. AB required lambda which is not unnecessary
Comment: Answer is D because it requires least operational overhead and S3 replication does the copying for you. Also read this https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html Lambda and Sagemaker are not supported destinations for S3 Event Notifications
Comment: Sorry i meant Sagemaker is not supported as an S3 Event Notification. Lambda is though. Still doesn't change what the answer is.... D
Comment: I go for C, because option C no need to configure event notifications, but D need to extra work to configure the event notification, for the least operation, option C is best choice
Comment: B is the first option I denied. Since it makes the event happens inside the analysis bucket to trigger the lambda function. so if the lambda function is running code to copy files from initial bucket to analysis bucket. Then this lambda function should be triggered by the event in initial bucket like once the data reaches in the initial bucket then lambda is triggered. D is the answer.
Comment: Utilizing a lambda function would introduce additional operational overhead, eliminating options A and B. S3 replication offers a simpler setup and efficiently accomplishes the task. S3 notifications cannot use SageMaker as a destination; the permissible destinations include SQS, SNS, Lambda, and Eventbridge, so C is out.
Comment: Create lambda for replication is overhead. This dismisses A and B S3 event notification cannot be directed to Sagemaker directly. This dismisses C Correct Answer: D
Comment: You are right. This is the key point - Sagemaker cannot be the destination of S3 event notification.
Comment: D provide the least operational overhead
Comment: Option D is the solution with the least operational overhead: Use S3 replication between buckets Send S3 events to EventBridge Add Lambda and SageMaker as EventBridge rule targets The reasons this has the least overhead: S3 replication automatically copies new objects to analysis bucket EventBridge allows easily adding multiple targets for events No custom Lambda function needed for copying objects Leverages managed services for event processing
Comment: Correct: D B & D the only possible as Sagemaker is not supported as target for S3 events. Using bucket replication as D mention is more efficient than using a lambda as B mention.
Comment: Option D is correct because it combines S3 replication, event notifications, and Amazon EventBridge to automate the copying of files from the initial S3 bucket to the analysis S3 bucket. It also allows for the execution of Lambda functions and integration with SageMaker Pipelines. Option A is incorrect because it suggests manually copying the files using a Lambda function and event notifications, but it does not utilize S3 replication or EventBridge for automation. Option B is incorrect because it suggests using S3 event notifications directly with EventBridge, but it does not involve S3 replication or utilize Lambda for copying the files. Option C is incorrect because it only involves S3 replication and event notifications without utilizing EventBridge or Lambda functions for further processing.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/notification-how-to-event-types-and-destinations.html#supported-notification-destinations S3 can NOT send event notification to SageMaker. This rules out C. you have to send to • Amazon EventBridge 1st then to SageMaker
Comment: Why I believe it is not C? The key here is in the s3:ObjectCreated:"Put". The replication will not fire the s3:ObjectCreated:Put. event. See link here: https://aws.amazon.com/blogs/aws/s3-event-notification/
Comment: D takes care of automated moving and lambda for pattern matching are covered efficiently in D.
Comment: only one destination type can be specified for each event notification in S3 event notifications
Comment: EC2 instance Savings Plan saves 72% while Compute Savings Plans saves 66%. But according to link, it says "Compute Savings Plans provide the most flexibility and help to reduce your costs by up to 66%. These plans automatically apply to EC2 instance usage regardless of instance family, size, AZ, region, OS or tenancy, and also apply to Fargate and Lambda usage." EC2 instance Savings Plans are not applied to Fargate or Lambda
Comment: Compute Savings Plans can be used for EC2 instances and Fargate. Whereas EC2 Savings Plans support EC2 only.
Comment: Ans A, C - A: Spot obvious for unpredictable, 'don't care' usage C: Not so obvious... but its more than just EC2 - its about Compute power using Fargate, Lambda, API call processing so it has to be C (as opposed to E)
Comment: Be mindful that the question is asking about API. So it should be Compute Savings Plans. If it is for EC2, the Reserved Instance will be correct.
Comment: Compute Savings Plans can also apply to Fargate and Lambda Usage.
Comment: BC is the answer data ingestion = Spot Instance but Keyword "Usage Unpredictable" : On-Demand and for APi its Compute Savings Plan
Comment: Spot instances can auto scale so Spot instance is correct.
Comment: The two most cost-effective purchasing options for this architecture are: A) Use Spot Instances for the data ingestion layer C) Purchase a 1-year Compute Savings Plan for the front end and API layer The reasons are: Spot Instances provide the greatest savings for flexible, interruptible EC2 workloads like data ingestion. Savings Plans offer significant discounts for predictable usage like the front end and API layer. All Upfront and partial/no Upfront RI's don't align well with the sporadic EC2 usage. On-Demand is more expensive than Spot for flexible EC2 workloads. By matching purchasing options to the workload patterns, Spot for unpredictable EC2 and Savings Plans for steady-state usage, the solutions architect optimizes cost efficiency.
Comment: Using Spot Instances for the data ingestion layer will provide the most cost-effective option for sporadic and unpredictable workloads, as Spot Instances offer significant cost savings compared to On-Demand Instances (Option A). Purchasing a 1-year Compute Savings Plan for the front end and API layer will provide cost savings for predictable utilization over the course of a year (Option C). Option B is less cost-effective as it suggests using On-Demand Instances for the data ingestion layer, which does not take advantage of cost-saving opportunities. Option D suggests purchasing 1-year All Upfront Reserved instances for the data ingestion layer, which may not be optimal for sporadic and unpredictable workloads. Option E suggests purchasing a 1-year EC2 instance Savings Plan for the front end and API layer, but Compute Savings Plans are typically more suitable for predictable workloads.
Comment: Spot instances for data injection because the task can be terminated at anytime and tolerate disruption. Compute Saving Plan is cheaper than EC2 instance Savings plan.
Comment: EC2 instance Savings Plans are not applied to Fargate or Lambda
Comment: Why not B?
Comment: because onDemand is more expensive than spot additionally that the workload has no problem with being interrupted at any time
Comment: To optimize the cost of running this application on AWS, you should consider the following options: A. Use Spot Instances for the data ingestion layer C. Purchase a 1-year Compute Savings Plan for the front-end and API layer Therefore, the most cost-effective solution for hosting this application would be to use Spot Instances for the data ingestion layer and to purchase either a 1-year Compute Savings Plan or a 1-year EC2 instance Savings Plan for the front-end and API layer.
Comment: Yes, but in the question it also states that it is 'Unpredictable' So, On-Demand is suitable over Spot Instance right which makes BC as the answer
Comment: the question clearly says "can be interrupted at any time" - anything that mentions these words with cost saving, you should automatically think Spot instances
Comment: Spot instances can auto scale so Spot is still correct.
Comment: Too obvious answer.
Comment: AC can be interrupted at any time => spot
Comment: A,E:: Savings Plan — EC2 Savings Plan offers almost the same savings from a cost as RIs and adds additional Automation around how the savings are being applied. One way to understand is to say that EC2 Savings Plan are Standard Reserved Instances with automatic switching depending on Instance types being used within the same instance family and additionally applied to ECS Fargate and Lambda. Savings Plan — Compute Savings Plan offers almost the same savings from a cost as RIs and adds additional Automation around how the savings are being applied. For example, they provide flexibility around instance types and regions so that you don't have to monitor new instance types that are being launched. It is also applied to Lambda and ECS Fargate workloads. One way to understand is to say that Compute Savings Plan are Convertible Reserved Instances with automatic switching depending on Instance types being used.
Comment: A and C
Comment: its A and C . https://www.densify.com/finops/aws-savings-plan
Comment: Answer is A. Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content https://www.examtopics.com/discussions/amazon/view/81081-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Also, option B does not use CloudFront which means all the traffic will go through the internet; So, despite deploying resources in two regions and using the lowest latency point, that public internet connection might probably be slower than a connection through a private aws network as Cloudfront can use.
Comment: Answer should be B, CloudFront reduces latency if its only static content, which is not the case here. For Dynamic content, CF cant cache the content so it sends the traffic through the AWS Network which does reduces latency, but it still has to travel through another region. For the case with 2 region and Route 53 latency routing, Route 53 detects the nearest resouce (with lowest latency) and routes the traffic there. Because the traffic does not have to travel to resources far away, it should have the least latency in this case here.
Comment: All it takes is for you to go to the Amazon Cloudfront webpage hosted by AWS where it tells you "Amazon CloudFront is a content delivery network (CDN) service that helps you distribute your static and dynamic content quickly and reliably with high speed". Answer is A bro. Your answer is B literally makes no sense. Do some studying.
Comment: Can you pls. provide a ref. link from where this info. got extracted?
Comment: this is link https://aws.amazon.com/es/blogs/aws-spanish/cloudfront-para-la-distribucion-de-contenido-estatico-y-dinamico/
Comment: What about accross the word :)
Comment: Cf works for both static and dynamic content
Comment: Ans B - "If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving their requests from the AWS Region that provides the lowest latency" ...because it needs to be dynamic: "Latency between hosts on the internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements taken over a period of time, and the measurements reflect these changes. A request that is routed to the Oregon Region this week might be routed to the Singapore Region next week." https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html
Comment: B for sure
Comment: With Amazon CloudFront, your end users connections are terminated at CloudFront locations closer to them, which helps in reducing the overall round trip time required to establish a connection. This is irrespective of static a dynamic content.
Comment: You can still have improved performance by distributing the dynamic traffic through CDN instead of ALB. Refer below link. Also for other 2 options, using just 2 other regions for world wide distribution doesn't make much of a sense. https://aws.amazon.com/cloudfront/dynamic-content/
Comment: CloudFront for Static Content: By leveraging Amazon CloudFront, static content such as images, stylesheets, and scripts can be cached and distributed globally across a network of edge locations. This ensures that users receive static content from the nearest edge location, reducing latency and improving performance. Serve Dynamic Content from ALB: Since dynamic content requires real-time processing and cannot be effectively cached at edge locations, serving dynamic content directly from the Application Load Balancer (ALB) is appropriate. The ALB can handle dynamic requests efficiently within the AWS Region where the application is deployed.
Comment: C was my choice for the reasons stated here. What am I missing?
Comment: How can you SERVE content from a load balancer? Amazon Cloudfront is designed for static and dynamic content. Why would you pick any other option that isn't A?
Comment: CloudFront improves the performance, availability, and security of your dynamic content but not the latency as compared to Route 53 Latency Routing policy. Hence option B https://aws.amazon.com/cloudfront/dynamic-content/
Comment: I choose option B. While CloudFront can accelerate content delivery by caching static content at edge locations, it may not be the most effective solution in this scenario. Since the portal delivers a mixture of static and dynamic content, leveraging Route 53 latency routing for dynamic content delivery ensures that users are directed to the nearest AWS Region hosting the dynamic content.
Comment: "Least amount of latency for all users" "across the world" = CloudFront, thus B and D are out. Also, deploying the stack in "two regions" would benefit those two regions, but not users "across the world". CloudFront can also cache dynamic content, thus A.
Comment: Answer is option A: Earth Networks uses a CDN so that they can provide dynamic and personalized web based content quickly to their users with very low latency and high performing response times. Specifically, they need to be able to provide local information to the end user, in near real time, and need a CDN that allows them to adjust things like time to live, query strings, and cookie information so that they can pass all that information back to the origin to pull just what the user needs.
Comment: Those are personalized content - where CloudFront could not help much.
Comment: "A" because cloud front is more efficient
Comment: A or B very close. But the (B) camp arguments earlier made me lean to B: Cloudfront doesn't help much for dynamic content, which is probably the bottleneck; On average, two dynamic server could cut response half.
Comment: Option D is the most suitable choice for minimizing latency for all users. It leverages the use of multiple AWS regions, geolocation routing, and the ALB to ensure that users are directed to the closest region, reducing latency for both static and dynamic content. This approach provides a high level of availability and performance for global users.
Comment: CloudFront to the rescue....whoosh
Comment: The solution that will ensure the LEAST amount of latency for all users is: A. Deploy the application stack in a single AWS Region. Use Amazon CloudFront to serve all static and dynamic content by specifying the ALB as an origin. Here's why: Option A (Single AWS Region, Amazon CloudFront for both static and dynamic content): Deploying the application stack in a single AWS Region helps reduce complexity and potential data synchronization issues that might arise from using multiple regions
Comment: Correct Answer: C AWS Global Accelerator and Amazon CloudFront are separate services that use the AWS global network and its edge locations around the world. CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery). Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions. Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover. Both services integrate with AWS Shield for DDoS protection.
Comment: Explained very well. ty
Comment: Thank you, your explanation helped me to better understand even the answer of question 29
Comment: On top of this, lambda would not be able to run application that is running on a modified Linux kernel. The answer is C .
Comment: The correct answer is Option C. To meet the requirements; * AWS Global Accelerator is a service that routes traffic to the nearest edge location, providing low latency and static IP addresses for the front-end tier. It supports UDP-based traffic, which is required by the application. * A Network Load Balancer is a layer 4 load balancer that can handle UDP traffic and provide static IP addresses for the application endpoints. * An EC2 Auto Scaling group ensures that the required number of Amazon EC2 instances is available to meet the demand of the application. This will help the front-end tier to provide the best possible user experience. Option A is not a valid solution because Amazon Route 53 does not support UDP traffic. Option B is not a valid solution because Amazon CloudFront does not support UDP traffic. Option D is not a valid solution because Amazon API Gateway does not support UDP traffic.
Comment: My mistake, correction on Option A, it is the Application Load Balancers do not support UDP traffic. They are designed to load balance HTTP and HTTPS traffic, and they do not support other protocols such as UDP.
Comment: Ans C - hint: "That tier must have low latency, route traffic to the nearest edge location, and provide static IP addresses for entry into the application endpoints." "AWS Global Accelerator... provides static IP addresses that provide a fixed entry point to your applications and eliminate the complexity of managing specific IP addresses for different AWS Regions and Availability Zones... [to] always routes user traffic to the optimal endpoint based on performance, reacting instantly to changes in application health, your user's location, and policies that you configure." https://aws.amazon.com/global-accelerator/faqs/
Comment: Non HTTP/S, the answer is always Global Accelerator without doubts. GA serves like Cloudfront on providing low latency through edge locations, with the exception of handling different protocols.
Comment: Whenever I see this line : "and provide static IP addresses for entry into the application endpoints." - my brain automatically thinks Global Accelerator.
Comment: If the situation demands for UDP or some protocols that are not at application level then it would be better to use Global Accelerator and here they need top notch perfromance hence using it with NLB would be the best answer. Cloud Front does not support UDP nor does it support use of NLB
Comment: UDP: NLB. Static IP: Global Accelerator.
Comment: UDP, static IP = Global Accelerator and Network Load Balancer
Comment: AWS Global Accelerator provides static IP addresses that serve as a fixed entry point to application endpoints. This allows optimal routing to the nearest edge location. Using a Network Load Balancer (NLB) allows support for UDP traffic, as NLBs can handle TCP and UDP protocols. The application runs on a modified Linux kernel, so using Amazon EC2 instances directly will provide the needed customization and low latency. The EC2 instances can be auto scaled based on demand to provide high availability. API Gateway and Application Load Balancer are more suited for HTTP/HTTPS and REST API type workloads. For a UDP gaming workload, Global Accelerator + NLB + EC2 is a better architectural fit.
Comment: AWS Global Accelerator is designed to improve the availability and performance of applications by routing traffic through the AWS global network to the nearest edge locations, reducing latency. By configuring AWS Global Accelerator to forward requests to a Network Load Balancer, UDP-based traffic can be efficiently distributed across multiple EC2 instances in an Auto Scaling group. Using Amazon EC2 instances for the application allows for customization of the Linux kernel and support for UDP-based traffic. This solution provides static IP addresses for entry into the application endpoints, ensuring consistent access for users. Option A suggests using AWS Lambda for the application, but Lambda is not suitable for long-running UDP-based applications and may not provide the required low latency. Option B suggests using CloudFront, which is primarily designed for HTTP/HTTPS traffic and does not have native support for UDP-based traffic. Option D suggests using API Gateway, which is primarily used for RESTful APIs and does not support UDP-based traffic.
Comment: aws global accelarator provides static IP addresses.
Comment: My choice is option C, due to the followings: Amazon Global accelator route the traffic to nearest edge locations, it supports UDP-based traffic, and it provides static ip addresses as well, hence C is right answer.
Comment: Answer : C CloudFront : Doesn't support static IP addresses ALB : Doesn't support UDP
Comment: C - https://aws.amazon.com/global-accelerator/
Comment: To meet the requirements of providing low latency, routing traffic to the nearest edge location, and providing static IP addresses for entry into the application endpoints, the best solution would be to use AWS Global Accelerator. This service routes traffic to the nearest edge location and provides static IP addresses for the application endpoints. The front-end tier should be configured with a Network Load Balancer, which can handle UDP-based traffic and provide high availability. Option C, "Configure AWS Global Accelerator to forward requests to a Network Load Balancer. Use Amazon EC2 instances for the application in an EC2 Auto Scaling group," is the correct answer.
Comment: C is obvious choice here.
Comment: C as Global Accelerator is the best choice for UDP based traffic needing static IP address.
Comment: I think the answer here is "D" because usually when you see terms like "monolithic" the answer will likely refer to microservices.
Comment: D is organic pattern, lift and shift, decompose to containers, first making most use of existing code, whilst new features can be added over time with lambda+api gw later. A is leapfrog pattern. requiring refactoring all code up front.
Comment: Ans D - hint: "...break the application into smaller applications"
Comment: Ans D - hint: "The company wants to keep as much of the front-end code and the backend code as possible. However, the company wants to break the application into smaller applications." Containerisation will help the company achieve a scaleable, more manageable solution.
Comment: For the folks suggesting Amplify: Have any of you actually shipped anything on Amplify? There are tons of adaptations needed to port a monolith to Amplify, specially around the backend that will need severe refactor. Answer D allows for decomposing the application into different containers, enabling a distributed monolith.
Comment: Amazon API Gateway and Amplify both server less. Also you can import your code from GitHub in the amplify.
Comment: Option D does not mention AWS Fargate which would cover the 'least operational overhead ' part.
Comment: The company wants to keep much of its existing code. So the preferable solution is ECS. However the option D does not mention AWS Fargate which would cover the 'least operational overhead ' part.
Comment: Different teams working means " microservices based architecture" so basically decoupling the application ..u can achieve this only by containerizing the app so answer is D
Comment: B allows for a serverless architecture using AWS Lambda functions, which are highly scalable and require minimal operational overhead. AWS Amplify can help in managing the front-end code, while Amazon API Gateway integrated with AWS Lambda can handle the backend services. D imo is not the best option in this scenario. While ECS can be a good choice for containerized workloads, it might introduce more operational overhead compared to a serverless solution like AWS Lambda and AWS Amplify.
Comment: I have a problem with this question. "The company wants to keep as much of the front-end code and the backend code as possible" So containerization is the solution here (D)? ABC don't make much sense so I will go with D but using containers for FE/BE code and configuring ALB for ECS (hopefully for frontend containers) is a pain in practice. Maybe this is worded in a bad way.
Comment: Original state: monolithic with FE and BE code Wanted state: seperate to mutilple components for diff. teams as Microservices B is correct to decouple monolithic to microservices. D still keep monolithic application in ECS.
Comment: IT is B. AWS amplify. AWS Amplify will help seperate FE and BE. I agree with MM_Korvinus answer.
Comment: https://aws.amazon.com/tutorials/break-monolith-app-microservices-ecs-docker-ec2/module-three/ This page explained clearly why D is the correct answer
Comment: 'Non-monolithic', 'smaller applications', 'minimized operational overhead' all screaming 'microservices'.
Comment: The reasons are: ECS allows running Docker containers, so the existing monolithic app can be containerized and run on ECS with minimal code changes. The app can be broken into smaller microservices by containerizing different components and managing them separately. ECS provides auto scaling capabilities to scale each microservice independently. Using an Application Load Balancer with ECS enables distributing traffic across containers and auto scaling. ECS has minimal operational overhead compared to managing EC2 instances directly. Serverless options like Lambda and API Gateway would require significant code refactoring which is not ideal for migrating an existing app.
Comment: Honestly, from my experience, the minimal operational overhead is with Amplify and API Gateway with lambdas. Both services have neat release features, you do not need to fiddle around ECS configurations as everything is server-less, which is also highly scalable. Eventhough it is much harder to refactor monolithic app to this set-up it is definitely easier to operate. Not talking about complexities around ALB.
Comment: I actually agree with this, they have a monolithic application that contains the Front-end and Back-end. They clearly state they want different teams managing different applications. This is telling me they want a team to manage the front-end and a team to manage the back-end. A,C and D suggest simply running copies of the monolith application (containing front and back end). So how will different teams manage different applications?? B is the only one that actually splits front and back end
Comment: How do you want to run a "monolithic application" in Lambda?
Comment: ECS provides a highly scalable and managed environment for running containerized applications, reducing operational overhead. By setting up an ALB with ECS as the target, traffic can be distributed across multiple instances of the application for scalability and availability. This solution enables different teams to manage each application independently, promoting team autonomy and efficient development. A is more suitable for event-driven and serverless workloads. It may not be the ideal choice for migrating a monolithic application and maintaining the existing codebase. B integrates with Lambda and API Gateway, it may not provide the required flexibility for breaking the application into smaller applications and managing them independently. C would involve managing the infrastructure and scaling manually. It may result in higher operational overhead compared to using a container service like ECS.
Comment: Option B: Migrating the monthly reporting to an Aurora Replica may be the most cost-effective solution because it involves creating a read-only copy of the database that can be used specifically for running large reports without impacting the performance of the primary database. This solution allows the company to scale the read capacity of the database without incurring additional hardware or I/O costs.
Comment: The incorrect solutions are: Option A: Migrating the monthly reporting to Amazon Redshift may not be cost-effective because it involves creating a new data store and potentially significant data migration and ETL costs. Option C: Migrating the Aurora database to a larger instance class may not be cost-effective because it involves changing the underlying hardware of the database and potentially incurring additional costs for the larger instance. Option D: Increasing the Provisioned IOPS on the Aurora instance may not be cost-effective because it involves paying for additional I/O capacity that may not be necessary for other workloads on the database.
Comment: Report = Aurora replica
Comment: Ans B - Using Aurora Replica means you can work off a snapshot without impacting the master DB
Comment: Ans B - making reports is temporary feature every month, so creating Aurora Replica is sufficient and efficient. Redshift is unnecessary (and means further overheads); C, D permanently upgrade capability which is not needed
Comment: This approach focuses directly on mitigating the observed IOPS spikes, which are likely contributing to the performance degradation during heavy report processing, without introducing additional complexities or higher operational costs associated with other options.
Comment: Aye B.
Comment: Migrate the monthly reporting to an Aurora Replica
Comment: Aurora Replicas utilize the same storage as the primary instance so there is no additional storage cost. Replicas can be created and destroyed easily to match reporting needs. The primary Aurora instance size does not need to be changed, avoiding additional cost. Workload is offloaded from the primary instance, improving its performance. No major software/configuration changes needed compared to options like Redshift.
Comment: I don't understand why doubling everything (instances, network cost, maintenance effort, and especially storage) can be considered "cost-saving" for a simple monthly report... An instance upgrade can very well be much cheaper. This question is very vague and does not provide enough information.
Comment: Silly me, I thought upgrading instance type includes storage upgrade (increase read iops) lol. The question pointed out that hard drive is also a limiting factor, so correct answer is B.
Comment: B is correct because migrating the monthly reporting to an Aurora Replica can offload the reporting workload from the primary Aurora instance, reducing the impact on its performance during large reports. Using an Aurora Replica provides scalability and allows the replica to handle the read-intensive reporting queries, improving the overall performance of the ecommerce application. A is wrong because migrating to Amazon Redshift introduces additional costs and complexity, and it may not be necessary to switch to a separate data warehousing service for this specific issue. C is wrong because simply increasing the instance class of the Aurora database may not be the most cost-effective solution if the performance issue can be resolved by offloading the reporting workload to an Aurora Replica. D is wrong because increasing the Provisioned IOPS alone may not address the issue of spikes in CPUUtilization during large reports, as it primarily focuses on storage performance rather than overall database performance.
Comment: By using an Aurora Replica for running large reports, the primary database will be relieved of the additional read load, improving performance for the ecommerce application.
Comment: Option B is right answer.
Comment: Finally a question where there are no controversies
Comment: The most cost-effective solution for addressing high ReadIOPS and CPU utilization when running large reports would be to migrate the monthly reporting to an Aurora Replica. An Aurora Replica is a read-only copy of an Aurora database that is updated in real-time with the primary database. By using an Aurora Replica for running large reports, the primary database will be relieved of the additional read load, improving performance for the ecommerce application. Option B, "Migrate the monthly reporting to an Aurora Replica," is the correct answer.
Comment: B is the best option
Comment: B is correct
Comment: B is correct
Comment: I was tempted to pick A but then I realized there are two key requirements: - scale seamlessly - cost-effectively None of A-C give seamless scalability. A and B are about adding second instance (which I assume does not match to "scale seamlessly"). C is about changing instance type. Therefore D is only workable solution to the scalability requirement
Comment: Yup. Got me too. I picked A, saw D, and then reread the "scale seamlessly" part. D is correct.
Comment: But wouldn't RDS scale as well? Also Spot instances seems like a bit of a risky decision
Comment: I wouldn't run my website on spot instances. Spot instances might be terminated at any time, and since I need to run analytics application it's not an option for me. And using route 53 for load balancing of 2 instances is an overkill. I go with A.
Comment: It is spot fleet - not spot instances. They can include On-Demand instances and can also maintain the target capacity automatically. ---- A Spot Fleet is a set of Spot Instances and optionally On-Demand Instances that is launched based on criteria that you specify. The Spot Fleet selects the Spot capacity pools that meet your needs and launches Spot Instances to meet the target capacity for the fleet. By default, Spot Fleets are set to maintain target capacity by launching replacement instances after Spot Instances in the fleet are terminated. Ref: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html
Comment: While Spot Fleet is temporary, the Auto-Scaling Group builds it back again and again. D is the best answer.
Comment: Ans D - Like Konb (1 year, 5 months ago) I almost picked A, but for the same reasons of seamless scaling it has to be D
Comment: D aswer is forcing you to use the new "feature" of aws. if you have a performance issue with the ddbb, front and back all in on your ec2 intances. the best way to solve that issue is move de ddbb to RDS and create a new ec2 intances. BUT we need to sell the aws unique service.
Comment: Ans D - I was tempted with AAns D - I was tempted with A but then thought that's too obvious and scaling might be an issue... so looking at Spot Fleets "Fleets provide the following features and benefits, enabling you to maximize cost savings and optimize availability and performance when running applications on multiple EC2 instances" it has to be Ans D. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Fleets.html
Comment: Option A is the best balance between cost-effectiveness and scalability. It allows the application to scale horizontally with minimal changes while ensuring the database is managed and can scale independently, reducing the risk of performance degradation during peak times.
Comment: i think it is not D, because amazon aurora is much expensive and also the spot instances can be interrupted, even they are most cost effective in the requirements is not mentioned that the workload is stateless and can be interrupted.
Comment: A, not D > Using Spot Instances with an Auto Scaling group adds complexity and risk to the infrastructure
Comment: It is not "spot instances", but "spot fleet". A Spot Fleet is a set of Spot Instances and optionally On-Demand Instances that is launched based on criteria that you specify. The Spot Fleet selects the Spot capacity pools that meet your needs and launches Spot Instances to meet the target capacity for the fleet. By default, Spot Fleets are set to maintain target capacity by launching replacement instances after Spot Instances in the fleet are terminated. Ref: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html
Comment: I don't think D is the optimal solution. We certainly can find other solutions that are more cost effective and fulfill the same requirements, but among the provided options, I think D is the most reasonable.
Comment: PHP....
Comment: I'll pick D because it sounds fun :)
Comment: "Scale seamlessly", none of A-C include scaling at all.
Comment: spot instance receives 2 minutes interruption notice, it should be enough for requests to finish, it's quite unusal for app to run longer requests only option D allow for seamless scaling with autoscaling group
Comment: Option B is a cost-effective choice that combines the benefits of database migration to RDS, horizontal scaling with EC2 instances, and control over traffic distribution with Route 53 weighted routing, making it the best solution for the given requirements.
Comment: But there's no scaling at all in B.
Comment: Scale seamlessly = Autoscaling group, Amazon Aurora MySQL DB instance Cost effective = Spot Fleet
Comment: The key reasons are: Migrating the database to Amazon Aurora MySQL provides a scalable, high performance database to support the application. Creating an AMI of the web application and using it in an Auto Scaling group with Spot instances allows cheap and efficient scaling of the web tier. The Application Load Balancer distributes traffic across the Auto Scaling group. Spot instances in an Auto Scaling group allow cost-optimized automatic scaling based on demand. This approach provides high availability and seamless scaling without manual intervention.
Comment: D is correct because migrating the database to Amazon Aurora provides better scalability and performance compared to Amazon RDS for MySQL. Creating an AMI of the web application allows for easy replication of the application on multiple instances. Using a launch template and Auto Scaling group with Spot Fleet provides cost optimization by leveraging spot instances. Adding an Application Load Balancer ensures the load is distributed across the instances for seamless scaling. A is incorrect because using an Application Load Balancer with multiple EC2 instances is a better approach for scalability compared to relying on a single instance. B is incorrect because weighted routing in Amazon Route 53 distributes traffic based on fixed weights, which may not dynamically adjust to the changing load. C is incorrect because using AWS Lambda to stop and change the instance type based on CPU utilization is not an efficient way to handle scaling for a web application. Auto Scaling is a better approach for dynamic scaling.
Comment: the options that said "launch a second EC2", have no sense ... why 2?, why not 3 or 4 or 5? so options A and B drop. C is no sense (Lambda doing this like a Scaling Group?, absurd) Has to be D. Little extrange cos' Aurora is a very good solution, but NOT CHEAP (remember: cost-effectively). To be honest, the most cost-effectively is B je je
Comment: In the Question is mentioned that it has o Demand instances...so I think is more cheapest reserved and spot
Comment: Answer is B: Reserved is cheaper than on demand the company has. And it's meet the availabilty (HA) requirement as to spot instance that can be disrupted at any time. PRICING BELOW. On-Demand: 0% There's no commitment from you. You pay the most with this option. Reserved : 40%-60%1-year or 3-year commitment from you. You save money from that commitment. Spot 50%-90% Ridiculously inexpensive because there's no commitment from the AWS side.
Comment: Ans B - Reserved guarantees baseline level operation; Spot for peaks - its stateless
Comment: B is the correct answer, using reserved instances is definitely more cost effective than using on-demand instances.
Comment: B for sure
Comment: Agree with others
Comment: This is a bit unclear, but B seems the best option of the ones given. Usage is either "heavy" (during the 8 hours), "moderate and steady" (overnight) or "low" (during weekends). So there is always SOME usage, which could be covered by a few Reserved Instances (which would be cheaper than On-Demand Instances). A - "Spot instances for the entire workload", might 'affect the availability of the application' B - Seems the best answer C - More expensive than B D - Dedicated instances aka dedicated hardware -> very expensive
Comment: Agree, very little clarity between B and C but B makes more sense.
Comment: I vote for C: Please explain me if I am wrong: If application experiences heavy usage during an 8-hour period each business day and all other time we don't need them? it mean than on-demand price will be only 33% from total cost so saving will be near 66%, more than reserved instances all other load we can cover by spot instances. So why it not C?
Comment: You got it wrong. You need the application all the time (24/7) because it says: "moderate and steady overnight, low usage at the weekend", not 8 hours a day
Comment: Selected Answer: C On-Demand Instances are more appropriate than Reserved Instances because "The application is used heavily for a period of 8 hours every weekday" requirements.
Comment: The answer should be C. Because if reserved is chosen, you have to pay for every hour. I calculate from this pages (if I'm wrong please correct me) https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/#:~:text=Reserved%20Instances%20provide%20you%20with,instances%20when%20you%20need%20them. Example: for t4g.nano Reserved instances (0.003X24X365)+(1.90X12)=49.08 On demand instance (0.0042X8X365)=12.264 it will be added spot instances
Comment: "The baseline level of usage" is the minimum usage that is always there (even at night and during weekends), for THAT you can use Reserved Instance.
Comment: B, since the application needs to be on 24/7 for business days; on weekends, it can be off at any moment. The question mentions something like 8 hour per business day but!!! this is just for heavy usage, the application is also on during overnight.
Comment: Why it's not A ? the application is "stateless" so it can be interrupted at any moment and the spot option is the cheaper one.
Comment: The statelessness of a web application does not necessarily mean that it's okay to be interrupted. Statelessness refers to how the application handles requests and manages session data, not its ability to handle interruptions.
Comment: But there might not be any Spot Instances available and the app would go offline.
Comment: If we assume moderate usage of 8 hours on average every day a week, this should be on demand, since it is not a 24/7 server. There is downtime on the weekends and after the initial 8 hours.
Comment: There is no downtime. The application runs all the time (even weekends). Weekends is the base workload which we cover with reserved instances, the higher workloads during the week is covered by spot instances.
Comment: Answer is C as the Jobs won't run for 24hrs/day hence Reserved instances is not required. As the Job runs for 8hrs/day we can choose On-Demand Instances
Comment: Which jobs runs for 8 hrs/day? There are 8 hours/day of HEAVY usage, but the app runs 24/7.
Comment: C is most cost effective option for running not 7x24 loads
Comment: I see some internet post about On-Demand vs Reserved below. I also think the argument from the (C) camp is valid. But (B) is not wrong. Just depends on usage. quoted from: https://www.pcapps.com/services/aws-reserved-vs-on-demand-instances/ If you know you are only going to use a particular server part-time – say, 8 hours a day, 5 days a week – we recommend purchasing On-Demand Instances for those servers. If you are unsure which instance type is most appropriate for your performance needs, our advice is to start with any On-Demand Instance for a month or two, and experiment with changing the Instance Type up or down to see it performs. The goal is to “dial into” the lowest cost instance type that meets your performance needs. We recommend that you purchase Reserved Instances only when you know you are going to use it close to 24×7 (or at least more than 75% of the time).
Comment: For 8 hours/day on demand works best
Comment: and Application usage is moderate and steady overnight!
Comment: Why not AwsBackup? No Glacier Deep is supported by AWS Backup https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html AWS Backup allows you to backup your S3 data stored in the following S3 Storage Classes: • S3 Standard • S3 Standard - Infrequently Access (IA) • S3 One Zone-IA • S3 Glacier Instant Retrieval • S3 Intelligent-Tiering (S3 INT)
Comment: AWS BackUp costs something, setting up S3 LCP doesn't.
Comment: Ans B - S3 with Glacier Deep plus Lifecycle management
Comment: S3 Lifecycle policies to the rescue
Comment: B is the most cost-effective solution. Storing the logs in S3 and using S3 Lifecycle policies to transition logs older than 1 month to S3 Glacier Deep Archive allows for cost optimization based on data access patterns. Since logs older than 1 month are rarely accessed, moving them to S3 Glacier Deep Archive helps minimize storage costs while still retaining the logs for the required 10-year period. A is incorrect because using AWS Backup to move logs to S3 Glacier Deep Archive can incur additional costs and complexity compared to using S3 Lifecycle policies directly. C adds unnecessary complexity and costs by involving CloudWatch Logs and AWS Backup when direct management through S3 is sufficient. D is incorrect because using S3 Lifecycle policies to move logs from CloudWatch Logs to S3 Glacier Deep Archive is not a valid option. CloudWatch Logs and S3 have separate storage mechanisms, and S3 Lifecycle policies cannot be applied directly to CloudWatch Logs.
Comment: B is correct..
Comment: Option B (Store the logs in Amazon S3. Use S3 Lifecycle policies to move logs more than 1-month-old to S3 Glacier Deep Archive) would meet these requirements in the most cost-effective manner. This solution would allow the application team to quickly access the logs from the past month for troubleshooting, while also providing a cost-effective storage solution for the logs that are rarely accessed and need to be retained for 10 years.
Comment: Option B is most cost effective. Moving logs to Cloudwatch logs may incure additional cost.
Comment: B is correct
Comment: S3 + Glacier is the most cost effective.
Comment: D works, archive cloudwatch logs to S3 .... but is an additional service to pay for over B.
Comment: CloudWatch logs can't store around 10 TB of data per month I believe so both C and D options are ruled out already.
Comment: https://www.examtopics.com/discussions/amazon/view/80772-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: *ensure that all notifications are eventually processed*
Comment: This is why https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html
Comment: Ans D - using SQS ensure the data is captured and not lost for processing
Comment: D for sure
Comment: Configure an Amazon Simple Queue Service (Amazon SQS) queue as the on-failure destination. Modify the Lambda function to process messages in the queue.
Comment: C is not the right answer since after several retries SNS discard the message which doesn't align with the reqirement. D is the right answer
Comment: Best solution to process failed SNS notifications is using sns-dead-letter-queues (SQS Queue for reprocessing) https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html
Comment: To ensure that all notifications are eventually processed, the best solution would be to configure an Amazon Simple Queue Service (SQS) queue as the on-failure destination for the SNS topic. This will allow the notifications to be retried until they are successfully processed. The Lambda function can then be modified to process messages in the queue, ensuring that all notifications are eventually processed. Option D, "Configure an Amazon Simple Queue Service (Amazon SQS) queue as the on-failure destination. Modify the Lambda function to process messages in the queue," is the correct answer.
Comment: I choose Option D as the correct answer. To ensure that all notifications are eventually processed, the solutions architect can set up an Amazon SQS queue as the on-failure destination for the Amazon SNS topic. This way, when the Lambda function fails due to network connectivity issues, the notification will be sent to the queue instead of being lost. The Lambda function can then be modified to process messages in the queue, ensuring that all notifications are eventually processed.
Comment: Option D to ensure that all notifications are eventually processed you need to use SQS.
Comment: Option C is right option. SNS does not have any "On Failure" delivery destination. One need to configure dead-letter queue and configure SQS to read from there. So given this option D is incorrect.
Comment: I don't think that's right "A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing" from https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html. This is pretty much what is being described in D. Plus C will only retry message processing, and network problems could still prevent the message from being processed, but the question states "ensure that all notifications are eventually processed". So C does not meet the requirements but D does look to do this.
Comment: + https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html "“To keep the message after the retries specified in the delivery policy are exhausted, configure your subscription to move undeliverables messages to a dead-letter queue (DLQ). For more information”" So D
Comment: Is correct.
Comment: If you want to ensure that all notifications are eventually processed you need to use SQS.
Comment: C isnt specific. Hence D
Comment: "on-failure destination" doesn't exist, only dead letter queue exist. that's why I am leaning for C
Comment: Dead letter queue doesnt exist in SNS. They are specifically saying a new queue will be configured for failures from SNS. Hence D
Comment: D is correct
Comment: D is the answer
Comment: Ans A - SQS (FIFO) ensures data is processed in the order it is received
Comment: "The data is written in a specific order that must be maintained throughout processing." A without reading other options.
Comment: Easiest question ever?
Comment: "specific order" = must be FIFO queue = only mentioned in A
Comment: Create an Amazon Simple Queue Service (Amazon SQS) FIFO queue to hold messages. Set up an AWS Lambda function to process messages from the queue.
Comment: A is the correct solution. By creating an Amazon Simple Queue Service (Amazon SQS) FIFO queue to hold messages and setting up an AWS Lambda function to process messages from the queue, the company can ensure that the order of the event data is maintained throughout processing. SQS FIFO queues guarantee the order of messages and are suitable for scenarios where strict message ordering is required. B is incorrect because Amazon Simple Notification Service (Amazon SNS) topics are not designed to preserve message order. SNS is a publish-subscribe messaging service and does not guarantee the order of message delivery. C is incorrect because using an SQS standard queue does not guarantee the order of message processing. SQS standard queues provide high throughput and scale, but they do not guarantee strict message ordering. D is incorrect because configuring an SQS queue as a subscriber to an SNS topic does not ensure message ordering. SNS topics distribute messages to subscribers independently, and the order of message processing is not guaranteed.
Comment: A is correct. Use FIFO to process in the specific order required
Comment: Option A is correct...data is processed in the correct order
Comment: The correct solution is Option A. Creating an Amazon Simple Queue Service (Amazon SQS) FIFO queue to hold messages and setting up an AWS Lambda function to process messages from the queue will ensure that the event data is processed in the correct order and minimize operational overhead. Option B is incorrect because using Amazon Simple Notification Service (Amazon SNS) does not guarantee the order in which messages are delivered. Option C is incorrect because using an Amazon SQS standard queue does not guarantee the order in which messages are processed. Option D is incorrect because using an Amazon SQS queue as a subscriber to an Amazon SNS topic does not guarantee the order in which messages are processed.
Comment: Only A is right option here.
Comment: Option A is the best option.
Comment: "The data is written in a specific order that must be maintained throughout processing" --> FIFO
Comment: specific order = FIFO
Comment: A is correct
Comment: Definitely A
Comment: A is correct
Comment: FIFO means order, so Option A.
Comment: Composite alarms determine their states by monitoring the states of other alarms. You can **use composite alarms to reduce alarm noise**. For example, you can create a composite alarm where the underlying metric alarms go into ALARM when they meet specific conditions. You then can set up your composite alarm to go into ALARM and send you notifications when the underlying metric alarms go into ALARM by configuring the underlying metric alarms never to take actions. Currently, composite alarms can take the following actions: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html
Comment: By creating composite alarms in CloudWatch, the solutions architect can combine multiple metrics, such as CPU utilization and read IOPS, into a single alarm. This allows the company to take action only when both conditions are met, reducing false alarms and focusing on meaningful alerts. B can help in monitoring the overall health and performance of the application. However, it does not directly address the specific requirement of triggering an action when CPU utilization and read IOPS exceed certain thresholds simultaneously. C. Creating CloudWatch Synthetics canaries is useful for actively monitoring the application's behavior and availability. However, it does not directly address the specific requirement of monitoring CPU utilization and read IOPS to trigger an action. D. Creating single CloudWatch metric alarms with multiple metric thresholds where possible can be an option, but it does not address the requirement of triggering an action only when both CPU utilization and read IOPS exceed their respective thresholds simultaneously.
Comment: Ans A - Cloudwatch composite alarms
Comment: With CloudWatch, you can combine several alarms into one composite alarm to create a summarized, aggregated health indicator over a whole application or group of resources. Composite alarms are alarms that determine their state by monitoring the states of other alarms. You define rules to combine the status of those monitored alarms using Boolean logic.
Comment: composite alarms are suited for scenarios where we have to combine the alarms for different metrics or dimensions, rather than for multiple threshold of the same metric. It contradict with option A.
Comment: Composite for multiple conditions like AND/OR combinations B: This option just made me laugh. Lol, will someone just sit and look at this dashboard? C: CW Synthetics canaries if for API D: Single won't monitor multiple metrics
Comment: A: Composite alarms determine their states by monitoring the states of other alarms. You can use composite alarms to reduce alarm noise. For example, you can create a composite alarm where the underlying metric alarms go into ALARM when they meet specific conditions.
Comment: Composite alarms was designed to handle this scenario.
Comment: The key reasons are: Composite alarms allow defining alarms with multiple metrics and conditions, like high CPU AND high read IOPS in this case. Composite alarms can avoid false positives triggered by a single metric spike. Dashboards help visualize but won't take automated action. Synthetics tests application availability but doesn't address the metrics. Single metric alarms with multiple thresholds can't correlate across metrics and may still trigger false positives. Composite alarms allow acting quickly when both CPU and IOPS are high, per the stated need.
Comment: The composite alarm goes into ALARM state only if all conditions of the rule are met.
Comment: Option A, creating Amazon CloudWatch composite alarms, is correct because it allows the solutions architect to create an alarm that is triggered only when both CPU utilization is above 50% and read IOPS on the disk are high at the same time. This meets the requirement to act as soon as possible if both conditions are met, while also reducing the number of false alarms by ensuring that the alarm is triggered only when both conditions are met.
Comment: The incorrect solutions are: In contrast, Option B, creating Amazon CloudWatch dashboards, would not directly address the requirement to trigger an alarm when both CPU utilization is high and read IOPS on the disk are high at the same time. Dashboards can be useful for visualizing metric data and identifying trends, but they do not have the capability to trigger alarms based on multiple metric thresholds. Option C, using Amazon CloudWatch Synthetics canaries, may not be the best choice for this scenario, as canaries are used for synthetic testing rather than for monitoring live traffic. Canaries can be useful for monitoring the availability and performance of an application, but they may not be the most effective way to monitor the specific metric thresholds and conditions described in this scenario.
Comment: Option D, creating single Amazon CloudWatch metric alarms with multiple metric thresholds, would not allow the solutions architect to create an alarm that is triggered only when both CPU utilization and read IOPS on the disk are high at the same time. Instead, the alarm would be triggered whenever any of the specified metric thresholds are exceeded, which may result in a higher number of false alarms.
Comment: A is correct answer
Comment: Option A
Comment: The AWS::CloudWatch::CompositeAlarm type creates or updates a composite alarm. When you create a composite alarm, you specify a rule expression for the alarm that takes into account the alarm states of other alarms that you have created. The composite alarm goes into ALARM state only if all conditions of the rule are met. The alarms specified in a composite alarm's rule expression can include metric alarms and other composite alarms.Using composite alarms can reduce alarm noise.
Comment: A is correct
Comment: agree with A and C https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_vpc.html#example_vpc_2
Comment: A. By using Control Tower, the company can enforce data residency guardrails and restrict internet access for VPCs and denies access to all Regions except the required ap-northeast-3 Region. C. With Organizations, the company can configure SCPs to prevent VPCs from gaining internet access. By denying access to all Regions except ap-northeast-3, the company ensures that VPCs can only be deployed in the specified Region. Option B is incorrect because using rules in AWS WAF alone does not address the requirement of denying access to all AWS Regions except ap-northeast-3. Option D is incorrect because configuring outbound rules in network ACLs and IAM policies for users can help restrict traffic and access, but it does not enforce the company's requirement of denying access to all Regions except ap-northeast-3. Option E is incorrect because using AWS Config and managed rules can help detect and alert for specific resources and configurations, but it does not directly enforce the restriction of internet access or deny access to specific Regions.
Comment: Ans A, C - Control Tower with Organisations configured. The two go together
Comment: AC for sure
Comment: B: Irrelevant WAF D: This is confusing so I'll ignore it. E: Wrong product A: Control Tower can have residency guard rails and block internet access. C: SCP is like a duplicate of A IMHO but it stops admins from circumventing A as Org policies cannot be overridden by admins unless they are org admins. Too moany assumptions
Comment: A. Use AWS Control Tower to implement data residency guardrails to deny internet access and deny access to all AWS Regions except ap-northeast-3. C. Use AWS Organizations to configure service control policies (SCPs) that prevent VPCs from gaining internet access. Deny access to all AWS Regions except ap-northeast-3.
Comment: Use Control Tower to implement data residency guardrails and Service Control Policies (SCPS) to prevent VPCs from gaining internet access.
Comment: AWS Control Tower guardrails and AWS Organizations SCPs provide centralized, automated mechanisms to enforce no internet connectivity for VPCs and restrict Region access to only ap-northeast-3.
Comment: Didn't know that SCPS (Service Control Policies) could be used to deny users internet access. Good to know. Always thought it's got controlling who can and can't access AWS Services.
Comment: Agree with Aand C https://aws.amazon.com/blogs/aws/new-for-aws-control-tower-region-deny-and-guardrails-to-help-you-meet-data-residency-requirements/
Comment: I choose C and D. For control tower, it can't be A because ap-northeast-3 doesn't support it! Also, in the case of E, it is detection and warning, so it is difficult to prevent internet connection (although the view is a little obscure).
Comment: I just check, now it's supported!!!
Comment: A and C
Comment: C/D A - CANNOT BE!!! AWS Control Tower is not available in ap-northeast-3! Check your B- for sure no C - SCPS (Service Control Policies)- For sure D - Deny outbound rule to be place in prod and also IAM Policy to deny Users creating services in AP-Northeast3 E - it creates an alert, which means it happens but an alert is triggered. so I think it's not good either.
Comment: False, Control Tower is in Osaka NorthEast 3 https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html
Comment: Control tower isn't available in AP-northeast-3 (only available in ap-northeast1 and 2 : https://www.aws-services.info/controltower.html) For answer E, it creates an alert, wich means it happens but an alert is triggered. so i think it's not good either. That's why i would go for C and D
Comment: False, Control Tower is in Osaka NorthEast 3 https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html
Comment: same page you posted: ap-northeast-3 Asia Pacific (Osaka) 2023-04-20 https://aws.amazon.com/controltower
Comment: It's availabe now on the same tink u pasted in earlier: ap-northeast-3 Asia Pacific (Osaka) 2023-04-20.
Comment: AWS Control tower is not available in ap-northeast-3! https://www.aws-services.info/controltower.html
Comment: What's wrong with B?
Comment: Denying access to all AWS Regions except ap-northeast-3 in the AWS account settings cannot be enforced. Each individual account owner would have to configure this on trust. They could easily change it to allow themselves access beyond the Asia Pacific Region. So, instead you configure access controls across ALL accounts by using service control policies (SCPs). Apply to the root & it will apply to all OUs and accounts in the organization.
Comment: A - CANNOT BE!!! AWS Control Tower is not available in ap-northeast-3! Check your consolle.
Comment: https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-lambda/ It is option D. Option A could have been applicable had it been AWS Systems Manager State Manager & not AWS Systems Manager Session Manager
Comment: A is true for sure. "Schedule Amazon RDS stop and start using AWS Systems Manager" Steps in the documentation: 1. Configure an AWS Identity and Access Management (IAM) policy for State Manager. 2. Create an IAM role for the new policy. 3. Update the trust relationship of the role so Systems Manager can use it. 4. Set up the automatic stop with State Manager. 5. Set up the automatic start with State Manager. https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-systems-manager/
Comment: The link you sent talks about "AWS Systems Manager State Manager", not "AWS Systems Manager Session Manager".
Comment: (A) & (D) both look correct & both are supported by a 2-part article. First part describes (D), the second (A). I don't have an issue with (A): Session vs State; I understand that State Manager is a capability of Systems Manager. Because Lambda is not free beyond the free-tier limit & (A) is more complete with IAM notes unlike (D), I would choose (A) on the exam. Schedule Amazon RDS stop and start using AWS Systems Manager (part-2) https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-systems-manager/ Schedule Amazon RDS stop and start using AWS Lambda (part-1) https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-lambda/
Comment: And ofcause, D is working, so if A also right, the question is wrong.
Comment: Look like State manager and Session manager use for difference purpose even both in same dashboard console.
Comment: D. You need to use AWS Systems Manager State Manager, not Systems Manager Session Manager.
Comment: Agree with study_aws1 comment. Lambda and event bridge solution is the correct answer. The option A was only possible if it had mentioned System manager state manager
Comment: we still pay for RDS even when the instance stops. So for cost-optimize -> C
Comment: While the instance is stopped, you're charged for storage and backups, but not for the DB instance hours. https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-lambda/#:~:text=While%20the%20instance%20is%20stopped%2C%20you%E2%80%99re%20charged%20for%20storage%20and%20backups%2C%20but%20not%20for%20the%20DB%20instance%20hours.
Comment: Although both A and D is a workable solution, the requirements is to minimum cost. The benefits of automating the startup and shutdown of RDS DB instances using Lambda allows organizations to further reduce compute costs and simplify the administration of database environments that don't need to be running continuously. https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-lambda/ For using system manager to accomplish the task works however keep in mind that although we're stopping the databases, the storage costs for the databases still apply. https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-systems-manager/ Initially I also thought that A would be the correct answer however looking at the administration and cost I would go for D as a better solution instead.
Comment: To automatically shutdown an RDS instance during 09:00 PM to 09:00 AM and have it available between 09:00 AM to 09:00 PM, you can use AWS Systems Manager Maintenance Windows. Create two Maintenance Windows - one to stop the RDS instance at 09:00 PM and another to start it at 09:00 AM. For each Maintenance Window, select the "AWS-StopRDSInstance" and "AWS-StartRDSInstance" runbooks respectively and specify the cron expression for the schedule. Tag the RDS instance with a name so it can be identified by the runbooks. The runbooks will then automatically stop and start the RDS instance on the specified schedule without needing any manual intervention.
Comment: This allows cost savings by shutting down the RDS instance during non-business hours while keeping it available during the day as per your requirements. Refer to the AWS documentation for more details on configuring Maintenance Windows and runbooks. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html https://repost.aws/questions/QUcVR5js8LSbOS_LE889Kdlg/automatically-stop-and-start-an-amazon-rds-db-instance-in-a-cdk-app
Comment: Guys, we still have to pay for RDS instance even we stopped it, isn't it?
Comment: While the instance is stopped, you're charged for storage and backups, but not for the DB instance hours. https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-lambda/#:~:text=While%20the%20instance%20is%20stopped%2C%20you%E2%80%99re%20charged%20for%20storage%20and%20backups%2C%20but%20not%20for%20the%20DB%20instance%20hours.
Comment: AWS Lambda functions can be used to start and stop RDS instances programmatically. EventBridge scheduled rules can trigger the Lambda functions at specified times daily. This allows fully automating the starting and stopping of RDS on a schedule to match usage patterns. RDS billing is per hour when instance is running, so stopping when not in use significantly reduces costs. Using Lambda and EventBridge is simpler and more robust than cron jobs on EC2. ElastiCache and Systems Manager Session Manager are useful tools but do not directly address scheduled RDS start/stop.
Comment: You can use AWS Lambda and Amazon EventBridge to schedule a Lambda function to stop and start the idle databases with specific tags to save on compute costs. https://aws.amazon.com/blogs/database/schedule-amazon-rds-stop-and-start-using-aws-lambda/#:~:text=you%20to%20schedule%20a-,Lambda%20function,-to%20stop%20and%20start
Comment: Here is the recommended solutions which describes choice D - https://aws.amazon.com/blogs/database/save-costs-by-automating-the-start-and-stop-of-amazon-rds-instances-with-aws-lambda-and-amazon-eventbridge/
Comment: AWS Lambda functions can be used to start and stop RDS instances programmatically. EventBridge scheduled rules can trigger the Lambda functions at specified times daily. This allows fully automating the starting and stopping of RDS on a schedule to match usage patterns. RDS billing is per hour when instance is running, so stopping when not in use significantly reduces costs. Using Lambda and EventBridge is simpler and more robust than cron jobs on EC2. ElastiCache and Systems Manager Session Manager are useful tools but do not directly address scheduled RDS start/stop.
Comment: By using AWS Lambda functions triggered by Amazon EventBridge scheduled rules, the company can automate the start and stop actions for the Amazon RDS for MySQL DB instance based on the 12-hour access period. This allows them to minimize costs by only running the DB instance when it is needed. Option A is not the most suitable solution because it refers to IAM policies for AWS Systems Manager Session Manager, which is primarily used for interactive shell access to EC2 instances and does not directly address the requirement of starting and stopping the DB instance. Option B is not the most suitable solution because it suggests using Amazon ElastiCache for Redis as a cache cluster, which may not provide the desired cost optimization for the DB instance. Option C is not the most suitable solution because launching an EC2 instance and configuring cron jobs to start and stop it does not directly address the requirement of minimizing costs for the Amazon RDS DB instance.
Comment: I got this question in real exam!
Comment: why we need more than one lambda function to start and stop DB instance? btw how many questions came from this site?
Comment: State Manager, a capability of AWS Systems Manager
Comment: Option D is correct
Comment: In a typical development environment, dev and test databases are mostly utilized for 8 hours a day and sit idle when not in use. However, the databases are billed for the compute and storage costs during this idle time. To reduce the overall cost, Amazon RDS allows instances to be stopped temporarily. While the instance is stopped, you're charged for storage and backups, but not for the DB instance hours. Please note that a stopped instance will automatically be started after 7 days. This post presents a solution using AWS Lambda and Amazon EventBridge that allows you to schedule a Lambda function to stop and start the idle databases with specific tags to save on compute costs. The second post presents a solution that accomplishes stop and start of the idle Amazon RDS databases using AWS Systems Manager.
Comment: Answer D Why Optoin D ? The Question talks about downloads are infrequent older than 90 days which means files less than 90 days are accessed frequently. Standard-Infrequent Access (S3 Standard-IA) needs a minimum 30 days if accessed before, it costs more. So to access the files frequently you need a S3 Standard . After 90 days you can move it to Standard-Infrequent Access (S3 Standard-IA) as its going to be less frequently accessed
Comment: I do not agree. The MOST cheaper option is B, because by choosing: D) Files older than 90 days will live eternally in the S3 Infrequently access layer at $0.0125/GB. B) Using Intelligent-Tiering files older than 90 days can be moved DIRECTLY to the "Archive access tier" (Glacier instant retrieval) at $0.004/GB, avoiding/skipping the "S3 Infrequently access layer". The question also seems to be according this assuption as says "and configure it to move objects to a less expensive storage tier after 90 days". https://aws.amazon.com/s3/pricing/?nc=sn&loc=4
Comment: I am taking back my answer, the right is D) as the "Archive access tier" check present in the "Intelligent-Tiering Archive configurations" is for "S3 Glacier flexible retrieval" which is not instant retrieval.
Comment: Archive Instant Access tier (automatic) If an object is not accessed for 90 consecutive days, the object moves to the Archive Instant Access tier. The Archive Instant Access tier provides low latency and high-throughput performance. --- This says it moves to instant retrieval class. Price for this is lesser than standard IA. Answer should be B
Comment: B/D seems possible answer. But, I'll go with "B". In the following table, S3 Intelligent-Tiering seems not so expansive than S3 Standard. https://aws.amazon.com/s3/pricing/?nc1=h_ls And, in the question "128KB" size is talking about S3 Intelligent-Tiering stuff.
Comment: also, there are probably several ringtones which aren't popular/used. Why keep them in S3 standard? The company would save money if s3 intelligent-tiering moves the unpopular ringtones to a more cost-effective tier than s3 standard.
Comment: This link also has me going with “B.” Specifying 128 KB in size is not a coincidence. https://aws.amazon.com/s3/storage-classes/intelligent-tiering/
Comment: because of tha link it is D. There are no retrieval charges in S3 Intelligent-Tiering. S3 Intelligent-Tiering has no minimum eligible object size, but objects smaller than 128 KB are not eligible for auto tiering. These smaller objects may be stored, but they'll always be charged at the Frequent Access tier
Comment: oh sorry it states objects are bigger than 128 KB. B is correct
Comment: have you tried to implement B? how do you configure Intelligent Tiering to move objects to a less expensive storage tier after 90 days? and which storage tier is this 'less expensive' ? the answer is clearly wrong ... correct answer is D
Comment: S3 Intelligent tiering is used when the access frequency is not known. I think 128KB is a deflector.
Comment: Ans D - as well explained by rjam (1 year, 11 months ago)
Comment: I am going with D instead of B because Intelligent-Tiering may work against you in this case. The company knows that the files are rarely accessed after 90 days. So even if a file is accessed on the 89th day, they would still want to "archive" that file the next day (again because they fully know the typical access behavior). However, Intelligent Tiering will reset the 90-day inactive clock starting on the 89th day (i.e. it will not archive the file until the 189th day assuming no other access).
Comment: D for sure
Comment: You can't configure Intelligent Tiering, that is the whole point of it. It's intelligent and moves things on its own so there is no 90 day configuration you can set. Therefore D is the answer.
Comment: Actually scrap that. I'm changing my answer to B. You can setup Intelligent Tiering to move data to an archive after 90 days. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html?icmpid=docs_amazons3_console#sc-dynamic-data-access https://aws.amazon.com/about-aws/whats-new/2021/11/s3-intelligent-tiering-archive-instant-access-tier/ Also the 128KB size is perfect for Intelligent Tiering. Tricky question indeed, one of those pointless ones that doesn't really make you a better or worse AWS Engineer
Comment: Some songs make comebacks. Lifecycle policy isn't intelligent enough to deal with a resurgence in popularity of a ringtone. 128KB in size makes files eligible for Intelligent-Tiering.
Comment: Clearly option D is the correct. This is not a trick question.
Comment: I think this is a kind of tricky question (B VS D) However: The Q stated "most accessed files readily available for its users." From this and correct me if I am wrong, I think B is a better solution since Amazon S3 Intelligent-Tiering working on "moving data to the most cost-effective access tier based on access frequency" while the S3 Standard-IA doesn't. Ref: https://aws.amazon.com/s3/storage-classes/
Comment: B. Move the files to S3 Intelligent-Tiering and configure it to move objects to a less expensive storage tier after 90 days. Explanation: S3 Intelligent-Tiering is a storage class that automatically moves objects between two access tiers: frequent access and infrequent access, based on access patterns. By configuring S3 Intelligent-Tiering to move objects to a less expensive storage tier after 90 days of infrequent access, the company can save money on storage costs while ensuring that the most accessed files remain readily available. This approach is more cost-effective than using S3 Standard-Infrequent Access (S3 Standard-IA) because it automatically adjusts storage tiers based on access patterns without the need for manual configuration or management.
Comment: Right answer is D
Comment: D is cheapest and managed by S3 Lifecycle policy A: Not readily available C: Wrong product B: No choice of '90 days' so you'll be paying for Intelligent Tiering unnecessarily for files to drop out of frequent access after the first 90 days.
Comment: B is the correct answer Kindly follow the below link for more information as proof https://aws.amazon.com/s3/storage-classes/
Comment: So D is the correct answer as IA is cheaper than Intelligent tier.
Comment: The key reasons: S3 Lifecycle policies can automatically transition objects from S3 Standard to S3 Standard-IA after 90 days. S3 Standard provides high performance for frequently accessed newer files. S3 Standard-IA costs 20-30% less than S3 Standard for infrequently accessed files. This matches access patterns - high performance for new files, cost savings for older files. S3 Intelligent Tiering has higher request costs and complexity for this simple access pattern. S3 Inventory lists objects and their properties but does not directly transition objects. Lifecycle policies provide automated transitions without manual intervention.
Comment: Amazon S3 Standard-Infrequent Access (S3 Standard-IA) has a minimum billable object size, which currently is 128KB. This means that even if the stored object is smaller than 128KB, Amazon S3 will charge for a minimum of 128KB of data.
Comment: Very tricky case. Besides all the arguments for both camps. I lean to (B). There is an article about the adoption of Intelligent-Tiering in the recent years to save money. Had the following text is "all files ready", I would picked (D): keeping the most accessed files readily available . for its users. I hope AWS gives "partial credit" for both (B) and (D) regardless which is the MOST cost-effective.
Comment: How do you 'configure Intelligent Tiering to move objects to a less expensive storage tier after 90 days'? It's called "intelligent" because it moves files intelligently, not after a schedule you specify.
Comment: S3 Intelligent-Tiering monitors access patterns and automatically moves objects to the Infrequent Access tier when they haven't been accessed for 30 consecutive days. After 90 days of no access, the objects are moved to the Archive Instant Access tier without performance impact or operational overhead. https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html
Comment: Implement an S3 Lifecycle policy that moves the objects from S3 Standard to S3 Standard-Infrequent Access (S3 Standard-1A) after 90 days. I would not try to overthink this.
Comment: B, The key is "No users can have the ability to modify or delete any files" and compliance mode supports that. I remember it this way: ( governance is like government, they set the rules but they can allow some people to break it :D )
Comment: I liked that thought of yours.. can you do more of these please? Thank you
Comment: Amazon S3 Object Lock 1. Governance mode - Only users with special permissions can overwrite, delete, or alter object ock settings 2. Compliance mode - No user, including the root user in an AWS account, can overwrite, delete, or alter object lock settings
Comment: Answer : B Reason: Compliance Mode. The key difference between Compliance Mode and Governance Mode is that there are NO users that can override the retention periods set or delete an object, and that also includes your AWS root account which has the highest privileges.
Comment: How about: The repository must allow a few scientists to add new files
Comment: Adding is not the same as changing :)
Comment: Compliance mode controls the object life span after creation. how this option restricts all scientists from adding new file? please explain.
Comment: Ans B - Compliance mode... but not sure that answers "allow only a few scientists to add new files"...?
Comment: First of all, Regal hold has no expiration before you remove it. So A makes no sense. After that Governance mode is breakable with permission, but Compilance mode is not even for root user cannot delete it. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Comment: B for sure
Comment: I almost chose A for this deciving line lol but it would be compliance mode as no user should be able to change objects:- The repository must allow a few scientists to add new files and must restrict all other users to read-only access.
Comment: Can someone please explain why the answer is not A. It said that The repository must allow a few scientists to add new files. So, i think some user must have permission to change it.
Comment: Legal hold – A legal hold provides the same protection as a retention period, but it HAS NO EXPIRATION DATE. Instead, a legal hold remains in place until you explicitly remove it. Legal holds are independent from retention periods and are PLACED ON INDIVIDUAL OBJECT VERSIONS.
Comment: Write Once Read Many - in compliance mode there is no restriction in adding but only changing existing objects
Comment: Unsure, B would meet the "must keep every file for a minimum of 1 year" requirement. (In theory C would too if you ignore the root user, but administrators could remove the policy.) But what about the 'a few scientists must be able to add new files'? None of the options mentions permissions for a special group.
Comment: agree that something is missing for "some users". ACD are not going to work flat out so B looks like right answer but with some language issues either in the question or the answer.
Comment: Agree. It looks like it's missing sth here.
Comment: Both Compliance & Governance mode protect objects against being deleted or changed. But in Governance mode some people can have special permissions. In this question, no user can delete or modify files; so the answer is Compliance mode only. Neither of these modes restrict user from adding new files.
Comment: Compliance Mode best suits this scenario because once an object is locked in compliance mode, its retention mode can't be changed, and its retention period can't be shortened.
Comment: B) seems to be the right option, because: Both option A) & B) allow to: - Scientists add new files & other users read-only access. - Keep files for a minimum of 1 year Only option B allows to: - Disable all users the ability to modify or delete any file. If A) were the correct option some scientis will be able to modify files, as if they were in charge of put an object lock same permission would allow them to remove the lock and consequently delete the file.
Comment: B) seems to be the right option, because: Both option A) & B) allow to: - Scientists add new files & other users read-only access. - Keep files for a minimum of 1 year Only option B allows to: - Disable all users the ability to modify or delete any file. If A) were the correct option some scientis will be able to modify files, as if they were in charge of put an object lock same permission would allow them to remove the lock and consequently delete the file.
Comment: S3 Object Lock provides the necessary features to enforce immutability and retention of objects in an S3. Compliance mode ensures that the locked objects cannot be deleted or modified by any user, including those with write access. By setting a retention period of 365 days, the company can ensure that every file in the repository is kept for a minimum of 1 year after its creation date. A does not provide the same level of protection as compliance mode. In governance mode, there is a possibility for authorized users to remove the legal hold, potentially allowing objects to be modified or deleted. C can restrict users from deleting or changing objects, but it does not enforce the retention period requirement. It also does not provide the same level of immutability and protection against accidental or malicious modifications. D does not address the requirement of preventing users from modifying or deleting files. It provides a mechanism for tracking changes but does not enforce the desired access restrictions or retention period.
Comment: Am I the only one to worry about leap years ?
Comment: In compliance mode, a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account. When an object is locked in compliance mode, its retention mode can't be changed, and its retention period can't be shortened. Compliance mode helps ensure that an object version can't be overwritten or deleted for the duration of the retention period. In governance mode, users can't overwrite or delete an object version or alter its lock settings unless they have special permissions. With governance mode, you protect objects against being deleted by most users, but you can still grant some users permission to alter the retention settings or delete the object if necessary. In Governance mode, Objects can be deleted by some users with special permissions, this is against the requirement.
Comment: its B, legal hold has no retention
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html
Comment: key :caching Option C
Comment: The reasons are: Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations around the world. Connecting the S3 buckets containing the media files to CloudFront will cache the content at global edge locations. This provides fast reliable access to users everywhere by serving content from the nearest edge location. CloudFront integrates tightly with S3 for secure, durable storage. Global Accelerator improves availability and performance for TCP/UDP traffic, not HTTP-based content delivery. DataSync and SQS are not technologies for a global CDN like CloudFront.
Comment: Ans C - Cloudfront is designed to do this...
Comment: Amazon CloudFront to the rescue
Comment: CloudFront is a content delivery network (CDN) service provided by AWS. It caches content at edge locations worldwide, allowing users to access the content quickly regardless of their geographic location. By connecting the S3 to CloudFront, the media files can be cached at edge locations, ensuring reliable and fast delivery to users. A. is a data transfer service that is not designed for caching or content delivery. It is used for transferring data between on-premises storage systems and AWS services. B. is a service that improves the performance and availability of applications for global users. While it can provide fast and reliable access, it is not specifically designed for caching media files or connecting directly to S3. D. is a message queue service that is not suitable for caching or content delivery. It is used for decoupling and coordinating message-based communication between different components of an application. Therefore, the correct solution is option C, deploying CloudFront to connect the S3 to CloudFront edge servers.
Comment: Global Accelerator does not support Edge Caching
Comment: Option C is correct answer.
Comment: As far as I understand, Global Accelerator does not have caching features, so CloudFront would be the recommended service for that purpose
Comment: C correto
Comment: C, Caching == Edge location == CloudFront
Comment: C right answer
Comment: Agreed
Comment: C is correct
Comment: Answer is C
Comment: I believe AE makes the most sense
Comment: yeah AE makes sense, only E is working with S3 here and questions wants them to be in S3
Comment: Ans A, D - A everyone seems to agree; I choose D over E because Parquet is aimed at columnar data - and that is not specified and may restrict query type access
Comment: AE satisfies the requirements that demand that the data should be stored in s3 and a one-time analytic will run on it.
Comment: C and D = too much overhead B = incorrect because Athena is used for one time queries. That leaves A and E
Comment: A is a given due to Athena and QuickSight option. Between C and E, the AWS Lake Formation is a more managed solution so it should have less operational overhead that writing Custom AWS Lambda. AE should be preferred over AC.
Comment: E is only confusing because of Apache Parquet format (like a grid?) what's the point of that in the context of this quesiton?
Comment: The reasons are: AWS Lake Formation and Glue provide automated data lake creation with minimal coding. Glue crawlers identify sources and ETL jobs load to S3. Athena allows ad-hoc queries directly on S3 data with no infrastructure to manage. QuickSight provides easy cloud BI for dashboards. Options C and D require significant custom coding for ETL and queries. Redshift and OpenSearch would require additional setup and management overhead.
Comment: It combines data from database and stream data, so data lake needs to be used. And it wants to do one time query, so Athena is better.
Comment: @Golcha once the data comes from different sources then you use GLUE
Comment: Less Overhead with option AC .No need to manage
Comment: But C moves the data to Redshift while the question says you want it in S3 (and Athena from answer A also needs it in S3).
Comment: No specific use case for GLUE
Comment: once the data comes from different sources then you use GLUE
Comment: C moves the data to Redshift while the question says you want it in S3 (and Athena from answer A also needs it in S3).
Comment: The Apache Parquet format is a performance-oriented, column-based data format designed for storage and retrieval. It is generally faster for reads than writes because of its columnar storage layout and a pre-computed schema that is written with the data into the files. AWS Glue's Parquet writer offers fast write performance and flexibility to handle evolving datasets. You can use AWS Glue to read Parquet files from Amazon S3 and from streaming sources as well as write Parquet files to Amazon S3. When using AWS Glue to build a data lake foundation, it automatically crawls your Amazon S3 data, identifies data formats, and then suggests schemas for use with other AWS analytic services[1][2][3][4].
Comment: ANSWER - AE:Amazon Athena is the best choice for running one-time queries on streaming data. Although Amazon Kinesis Data Analytics provides an easy and familiar standard SQL language to analyze streaming data in real-time, it is designed for continuous queries rather than one-time queries[1]. On the other hand, Amazon Athena is a serverless interactive query service that allows querying data in Amazon S3 using SQL. It is optimized for ad-hoc querying and is ideal for running one-time queries on streaming data[2].AWS Lake Formation uses as a central place to have all your data for analytics purposes (E). Athena integrate perfect with S3 and can makes queries (A).
Comment: AWS Lake Formation uses as a central place to have all your data for analytics purposes (E). Athena integrate perfect with S3 and can makes queries (A).
Comment: Why S3 in Apache Parquet? https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-s3-announces-parquet-output-format-for-inventory/
Comment: Can anyone please explain me why B cannot be an answer?
Comment: Kinesis Data Analytics is designed for continuous queries rather than one-time queries.
Comment: can anyone help me in below question 36. A company has a Java application that uses Amazon Simple Queue Service (Amazon SOS) to parse messages. The application cannot parse messages that are large on 256KB size. The company wants to implement a solution to give the application the ability to parse messages as large as 50 MB. Which solution will meet these requirements with the FEWEST changes to the code? a) Use the Amazon SOS Extended Client Library for Java to host messages that are larger than 256 KB in Amazon S3. b) Use Amazon EventBridge to post large messages from the application instead of Aaron SOS c) Change the limit in Amazon SQS to handle messages that are larger than 256 KB d) Store messages that are larger than 256 KB in Amazon Elastic File System (Amazon EFS) Configure Amazon SQS to reference this location in the messages.
Comment: I will do "A" as well.
Comment: A would probably be the best answer. Sqs extended client library is for Java apps.
Comment: I believe DE makes the most sense
Comment: Why use OpenSearch service?
Comment: I tend to agree D and E... A - Manual task that can be automated, so why make life difficult? B - The maximum retention period is 35 days, so would not help C - The maximum retention period is 35 days, so would not help D - Only option that deals with logs, so makes sense E - Partially manual but only option that achieves the 5 year goal
Comment: 100% agree
Comment: dude trust me
Comment: https://medium.com/@darekhale91/how-to-pass-amazon-saa-c03-exam-dumps-2023-583619ddbcc8
Comment: No, please show your reasoning, you may be wrong. Remember, no one thinks they are wrong, but some always are :)
Comment: hehe... hehe
Comment: Ans D, E
Comment: D + E I think. D deals with the logs. AWS Backup for backups.... Why make backups more difficult by not using the built in backup tool?
Comment: I'd say "A" over "E" because in the option "E", it says use AWS Backup to take the "backups" not snapshot. "If you use AWS CLI, this is set using the parameter DeleteAfterDays. The retention period for snapshots can range between 1 day and 100 years (or indefinitely if you don't enter one), while the retention period for continuous backups can range from 1 day to 35 days. The creation date of a backup is the date the backup job started, not the date it completed. If your backup job doesn't complete on the same date it started, use the date on which it began to help calculate retention periods." From here: https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html
Comment: Agree with the reasoning of JayBee
Comment: C - C - https://www.bing.com/ck/a?!&&p=7e852c106834b9bdJmltdHM9MTcxMzM5ODQwMCZpZ3VpZD0xNzJiMThiOS1kM2RiLTZlZGEtMWNhZC0wYjRlZDJiZDZmZDYmaW5zaWQ9NTQ0OQ&ptn=3&ver=2&hsh=3&fclid=172b18b9-d3db-6eda-1cad-0b4ed2bd6fd6&psq=does+Aurora+offer+auto+backup&u=a1aHR0cHM6Ly9kb2NzLmF3cy5hbWF6b24uY29tL0FtYXpvblJEUy9sYXRlc3QvQXVyb3JhVXNlckd1aWRlL0F1cm9yYS5NYW5hZ2luZy5CYWNrdXBzLmh0bWwjOn46dGV4dD1BdXJvcmElMjBiYWNrcyUyMHVwJTIweW91ciUyMGNsdXN0ZXIlMjB2b2x1bWUlMjBhdXRvbWF0aWNhbGx5JTIwYW5kLHRvJTIwYW55JTIwcG9pbnQlMjB3aXRoaW4lMjB0aGUlMjBiYWNrdXAlMjByZXRlbnRpb24lMjBwZXJpb2Qu&ntb=1 D - Only answer for audit logs of activities on database
Comment: My thoughts: 1. AWS backups is designed to make back ups 2. "configure backup retention for 5 years" with what? a script? maybe AWS backups???? are the back ups done with DD and stored in S3? i cannot trust this answer 3. "Take a manual snapshot of the DB cluster" this is not an amazon best practice they want us to use their tools AWS backups 4. "create a life cycle policy" assuming the back ups are stored in S3 (which is not a best practice) cannot trust this that leaves D and E
Comment: D AND E- makes more sense as we automate backups in Aurora DB - Export data to CloudWatch to capture all log events and configure CloudWatch to retain logs indefinitely.
Comment: D and E. A would work as well, but D is the better option as its automated. E is the only option that gets you to the 5 year retention.
Comment: D AND E- makes more sense as we automate backups in Aurora DB - Export data to CloudWatch to capture all log events and configure CloudWatch to retain logs indefinitely.
Comment: DE makes more sense
Comment: The reasons are: Configuring the automated backups for the Aurora PostgreSQL DB cluster to retain backups for 5 years will meet the requirement to store all data for that duration. Exporting the database logs to CloudWatch Logs will capture the audit logs of actions performed in the database. CloudWatch Logs retention can be configured to store logs indefinitely. This meets the need to keep audit logs available beyond the 5 year data retention period. Additional manual snapshots or using AWS Backup for backups is not necessary since automated backups are already enabled. A lifecycle policy is useful for transitioning storage classes but does not apply here for a set 5 year retention.
Comment: Automated backup is limited 35 days
Comment: Previously, you had to create custom scripts to automate backup scheduling, enforce retention policies, or consolidate backup activity for manual Aurora cluster snapshots, especially when coordinating backups across AWS services. With AWS Backup, you gain a fully managed, policy-based backup solution with snapshot scheduling and snapshot retention management. You can now create, manage, and restore Aurora backups directly from the AWS Backup console for both PostgreSQL-compatible and MySQL-compatible versions of Aurora. To get started, select an Amazon Aurora cluster from the AWS Backup console and take an on-demand backup or simply assign the cluster to a backup plan.
Comment: https://aws.amazon.com/about-aws/whats-new/2020/06/amazon-aurora-snapshots-can-be-managed-via-aws-backup/?nc1=h_ls
Comment: A is not a valid option for meeting the requirements. A manual snapshot of the DB cluster is a point-in-time copy of the data in the cluster. While taking manual snapshots can be useful for creating backups of the data, it is not a reliable or efficient way to meet the requirement of storing all the data for 5 years and deleting it after 5 years. It would be difficult to ensure that manual snapshots are taken regularly and retained for the required period of time. It is recommended to use a fully managed backup service like AWS Backup, which can automate and centralize the process of taking and retaining backups.
Comment: Sorry, B and E that correct B. Create a lifecycle policy for the automated backups. This would ensure that the backups taken using AWS Backup are retained for the desired period of time.
Comment: I think a lifecycle policy would only keep backups for 35 days
Comment: Thats not correct ( i thought it was but I went and looked it up) Aurora only keeps backups from 1-35 days.
Comment: D and E only
Comment: A is right You can use CloudFront to deliver video on demand (VOD) or live streaming video using any HTTP origin Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses
Comment: website = http = cloudfront, if it is UDP, then global accelerator
Comment: Ans A - CloudFront delivers video on demand or live streaming video using any HTTP origin
Comment: A is right answer.
Comment: A for sure
Comment: AD is correct. link here https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html
Comment: A. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/on-demand-streaming-video.html
Comment: use CloudFront to deliver video on demand (VOD) or live streaming video using any HTTP origin
Comment: Option A (Amazon CloudFront) is a content delivery network (CDN) service that can improve the performance of on-demand streaming by caching and delivering content from edge locations. While it can accelerate on-demand streaming, it may not provide the same level of optimization for real-time streaming as AWS Global Accelerator.
Comment: A is pperfect https://d1.awsstatic.com/whitepapers/amazon-cloudfront-for-media.pdf
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/on-demand-streaming-video.html CloudFront solves the problem of streaming over Amazon CDN on global scale. "B" AWS Global Accelerator won't be suitable for streaming from web server as it does not provide edge caching like CDN. Global Accelerator only points the user to nearest functioning node which is helpful for real-time streaming but not best for on-demand.
Comment: https://aws.amazon.com/cloudfront/streaming/
Comment: A IS THE RIGHT ANS . Amazon CloudFront is a content delivery network (CDN) service offered by AWS. It is designed to deliver data, including videos and other media files, with low latency and high transfer speeds. This is a suitable option for optimizing website performance, especially for streaming content globally.
Comment: Although CloudFront is a content delivery network (CDN) that can provide low-latency and high-performance content delivery, its performance for real-time streaming and on-demand streaming may not be as professional as AWS Global Accelerator
Comment: https://aws.amazon.com/global-accelerator/ "AWS Global Accelerator is a networking service that helps you improve the availability, performance, and security of your public applications. Global Accelerator provides two global static public IPs that act as a fixed entry point to your application endpoints, such as Application Load Balancers, Network Load Balancers, Amazon Elastic Compute Cloud (EC2) instances, and elastic IPs." It is Anycast which connect user to closest resource on your server like ALB etc or ergional services. CloudFront is CDN and pushes your content to edge locations near the user. This solves all issues of latency and performance
Comment: You can use CloudFront to deliver video on demand (VOD) or live streaming video using any HTTP origin Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses
Comment: CloudFront offers several options for streaming your media to global viewers—both pre-recorded files and live events. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/IntroductionUseCases.html#IntroductionUseCasesStreaming For video on demand (VOD) streaming, you can use CloudFront to stream in common formats such as MPEG DASH, Apple HLS, Microsoft Smooth Streaming, and CMAF, to any device. For broadcasting a live stream, you can cache media fragments at the edge, so that multiple requests for the manifest file that delivers the fragments in the right order can be combined, to reduce the load on your origin server.
Comment: Please stop posting answers from ChatGPT. "The event is expected to attract a global online audience." Global Accelerator is a service that accelerates traffic to Google Cloud services from users around the world. If you're looking to stream audio content to a global audience, Global Accelerator may be more suitable due to its ability to route traffic through the nearest edge locations and reduce latency. However, if you're looking to stream audio content from a single source to a local audience, CloudFront may be a better option.
Comment: CloudFront for "local audience"???
Comment: the question says Global audience
Comment: C) WAF has bot identification and remedial tools, so it's CORRECT. A) remember the question : "...block requests from unauthorized users?" -- an api key is involved in a authorization process. It's not the more secure process, but it's better than an totoally anonymous process. If you don't know the key, you can't authenticate. So the bots, at least the first days/weeks could not access the service (at the end they'll do, cos' the key will be spread informally). So it's CORRECT. B) Implement a logic in the Lambda to detect fraudulent ip's is almost impossible, cos' it's a dynamic and changing pattern that you cannot handle easily. D) creating a rol is not going to imply be more protected from unauth. request, because a rol is a "principal", it's not involved in the authorization process.
Comment: Don't use API keys for authentication or authorization to control access to your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, to control access to your API, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.
Comment: E "An IAM role for EACH (!) user ATTEMPTING (!) to access the API"? Hello no.
Comment: Ans A, C - A: using API keys and usage plans restricts access to your API to users who have the key, limiting fraudulent access. C: designed to fight bots
Comment: C) Everyone agrees on C B) Almost impossible cos how do you detect fraudulent IP address from a publicly accessible application D) It's a publicly accessible application, converting the API to a private one defeats the purpose E) IAM role for each user trying to access a publicly accessible API is impossible. It like creating an IAM for each user that tries to use google AUTH for their website A) By implementing API keys and usage plans, you can restrict access to your API to only those users who possess the key, helping to limit fraudulent access.
Comment: AC is right answer.
Comment: AC for sure
Comment: Do the people voting E realize how insane that is? Creating a local IAM user in your account for every user that needs to access the API. No just... no.
Comment: B. Integrate logic within the Lambda function to ignore the requests from fraudulent IP addresses. -> you can think about CORS script write on Lambda to prevent fraudulent IP addresses. C. Implement an AWS WAF rule to target malicious requests and trigger actions to filter them out. -> No comment here as it can use to filter traffic
Comment: C and D are the perfect answers
Comment: Don't use API keys for authentication or authorization to control access to your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, to control access to your API, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.
Comment: I'll throw a curveball over here. "C" is a given as WAF rules can target malicious usage. For example: https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-waf-ip-reputation.html "D" Convert existing public API to a private API. This part is same as A. The additional bit over here is to change the DNS record to a new API endpoint which blocks the requests from unauthorised users also. The unauthorised users will not be redirected from public to private API endpoint. I am assuming that the public API endpoint will be used for authorisation and only authorised users will be redirected to private endpoint. This is more robust as the actual API (private endpoint) never gets hit with requests from unauthorised bots and WAF redirects it back to public URL. Happy to be corrected and challenged
Comment: It's a globally published API if you make it private how do other people access it ? A would be the better solution than D
Comment: The combination of using an API key and implementing an AWS WAF rule provides the most comprehensive and effective way to block requests from unauthorized users and protect the company's serverless application from botnet attacks.
Comment: A. Create plans using API keys shared only with real users: While using API keys is a standard way to control access to APIs, using API keys alone may not completely prevent attacks from botnets. Malicious request. B. Incorporate logic in the Lambda function to ignore requests from fraudulent IP addresses: This may be a solution, but filtering that relies more on IP addresses may not be as flexible as using AWS WAF. D. Convert an existing public API to a private API. Update DNS records to redirect users to the new API endpoint: This approach makes the API private, but requires user redirects and may inconvenience existing users.
Comment: C) WAF has bot identification and remedial tools, so it's CORRECT. A) remember the question : "...block requests from unauthorized users?" -- an api key is involved in a authorization process. It's not the more secure process, but it's better than an totoally anonymous process. If you don't know the key, you can't authenticate. So the bots, at least the first days/weeks could not access the service (at the end they'll do, cos' the key will be spread informally). So it's CORRECT.
Comment: Agree A and C I don't see how E is feasible as its a public API. How would you create an IAM role for each user?
Comment: AWS WAF rule to target and filter out malicious requests and API key to authorize users.
Comment: The reasons are: An API key with a usage plan limits access to only authorized apps and users. This prevents general public access. WAF rules can identify and block malicious bot traffic through pattern matching and IP reputation lists. Together, the API key and WAF provide preventative and detective controls against unauthorized requests. The other options add complexity or are reactive. IAM roles per user is not feasible for a public API. Ignoring requests in Lambda and changing DNS are response actions after an attack.
Comment: AC it's essential to note that while API keys are commonly associated with private APIs, they can also be used in conjunction with public APIs. In some cases, even public APIs may require API keys to control usage and monitor how the API is being utilized. The API provider might enforce usage limits, track API usage, or monitor for potential misuse, all of which can be managed effectively using API keys. In summary, API keys are not exclusive to private APIs and can be used for both private and public APIs, depending on the specific requirements and use case of the API provider.
Comment: Ans C: Cost-effective solution with milliseconds of retrieval -> it should be s3 standard
Comment: Ans C - S3 std: cost-effective, milliseconds of retrieval
Comment: S3 Standard
Comment: also s3 can store any form of data
Comment: Only Glacier class that would meet the requirement is Instant Retrieval, but it has 90 days minimum storage time which would kill the cost savings.
Comment: 300 MB / month storage without retrieval when file is single 300 MB file: S3 Standard cost (Monthly): 0.01 USD S3 Standard cost (Upfront): 0.00 USD S3 Glacier Instant Retrieval cost (Monthly): 0.00 USD if it was 3GB: 3 GB / month storage without retrieval when file is single 3GB file: S3 Standard cost (Monthly): 0.07 USD S3 Standard cost (Upfront): 0.00 USD S3 Glacier Instant Retrieval cost (Monthly): 0.01 USD When assumed no retrieval is required because it's DR solution, and it's a single file, Glacier Instant Retrieval wins, and when they mention S3 glacier we must choose one of the sub-category
Comment: but if 300 MB is divided into smaller files situation changes which is probably the case.. 300 MB / month storage without retrieval when files are 600x0.5MB : S3 Standard cost (Monthly): 0.01 USD S3 Standard cost (Upfront): 0.00 USD S3 Glacier Instant Retrieval cost (Monthly): 0.01 USD S3 Glacier Instant Retrieval cost (Upfront): 0.02 USD 3 GB / month storage without retrieval when files are 6000x0.5 MB file: S3 Standard cost (Monthly): 0.10 USD S3 Standard cost (Upfront): 0.03 USD S3 Glacier Instant Retrieval cost (Monthly): 0.13 USD S3 Glacier Instant Retrieval cost (Upfront): 0.25 USD
Comment: Only Glacier Instant Retrieval (which is not mentioned in B) would meet the access requirement, but "Objects that are archived to S3 Glacier Instant Retrieval and S3 Glacier Flexible Retrieval are charged for a minimum storage duration of 90 days."
Comment: Answer is not B because S3 glacier and S3 glacier instant storage are two different types of storage class. So, answer here is C: S3 standard
Comment: Data must be accessible in milliseconds and must be kept for 30 days = Amazon S3 Standard
Comment: ANS - C
Comment: The reasons are: S3 Standard provides high durability and availability for storage It allows millisecond access to retrieve objects Objects can be stored for any duration, meeting the 30 day retention need Storage costs are low, around $0.023 per GB/month OpenSearch and RDS require running and managing a cluster for DR storage Glacier has lower cost but retrieval time is too high at 3-5 hours S3 Standard's simplicity, high speed access, and low cost make it optimal for this small DR dataset that needs to be accessed quickly
Comment: https://aws.amazon.com/s3/storage-classes/glacier/instant-retrieval/
Comment: Not mentioned in B, and 90 days minimum storage time.
Comment: S3 Standard is a highly durable and scalable storage option suitable for backup and disaster recovery purposes. It offers millisecond access to data when needed and provides durability guarantees. It is also cost-effective compared to other storage options like OpenSearch Service, S3 Glacier, and RDS for PostgreSQL, which may have higher costs or longer access times for retrieving the data. A. OpenSearch Service (Elasticsearch Service): While it offers fast data retrieval, it may incur higher costs compared to storing data directly in S3, especially considering the amount of data being generated. B. S3 Glacier: While it provides long-term archival storage at a lower cost, it does not meet the requirement of immediate access in milliseconds. Retrieving data from Glacier typically takes several hours. D. RDS for PostgreSQL: While it can be used for data storage, it may be overkill and more expensive for a backup and disaster recovery solution compared to S3 Standard, which is more suitable and cost-effective for storing and retrieving data.
Comment: https://aws.amazon.com/s3/storage-classes/glacier/instant-retrieval/
Comment: "Objects that are archived to S3 Glacier Instant Retrieval and S3 Glacier Flexible Retrieval are charged for a minimum storage duration of 90 days." Also Instant Retrieval is not mentioned in B.
Comment: A. Incorrect Amazon OpenSearch Service (Amazon Elasticsearch Service) is designed for full-text search and analytics, but it may not be the most cost-effective solution for this use case B. Incorrect S3 Glacier is a cold storage solution that is designed for long-term data retention and infrequent access. C. Correct S3 standard is cost-effective and meets the requirement. S3 Standard allows for data retention for a specific number of days. D. PostgreSQL is a relational database service and may not be the most cost-effective solution.
Comment: Selected Answer: B S3 Glacier Instant Retrieval – Use for archiving data that is rarely accessed and requires milliseconds retrieval. https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html
Comment: Option C
Comment: JSON is object notation. S3 stores objects.
Comment: solution should remove operation overhead -> s3 -> lambda -> aurora
Comment: Aurora supports mysql and postgresql but question has database sql server. So, that eliminates B. So, the other logical answer is D. IMHO. Btw, i also thought the answer is B and started re-reading question carefully.
Comment: sql database, not sql server
Comment: By placing the JSON documents in an S3 bucket, the documents will be stored in a highly durable and scalable object storage service. The use of AWS Lambda allows the company to run their Python code to process the documents as they arrive in the S3 bucket without having to worry about the underlying infrastructure. This also allows for horizontal scalability, as AWS Lambda will automatically scale the number of instances of the function based on the incoming rate of requests. The results can be stored in an Amazon Aurora DB cluster, which is a fully-managed, high-performance database service that is compatible with MySQL and PostgreSQL. This will provide the necessary durability and scalability for the results of the processing.
Comment: Ans D - because none of the other answers guarantee FIFO. What if a subsequent JSON operation is intended to update an existing database record (which is highly likely) - then the wrong change would be applied
Comment: b is the right answer it very obvious
Comment: Guys I have a question. We dont know how long the processing of JSON documents is going to take. What if that processing takes more than 15 min ? Lambda can run only for 15 correct ? Based on this the answer could be D Please correct my understanding.
Comment: "D" has a lot of moving parts and more operational overhead even if each part is a managed service in itself. Also, if something can be done with Lambda, don't use an EC2 instance in any form as it always increases operational overhead (compared to Lambda).
Comment: "D" is just like the most complex one, sometimes the admin make mistakes and don't realize. lambda is a service make for this
Comment: B is correc
Comment: Main requirement is: 'scalability and minimized operational overhead' = serverless = Amazon S3 bucket, AWS Lambda function, Amazon Aurora DB cluster
Comment: - Using Lambda functions triggered by S3 events allows the Python code to automatically scale up and down based on the number of incoming JSON documents. This provides high availability and maximizes scalability. - Storing the results in an Amazon Aurora DB cluster provides a managed, scalable, and highly available database. - This serverless approach minimizes operational overhead since Lambda and Aurora handle provisioning infrastructure, deploying code, monitoring, patching, etc.
Comment: The answer is B. Place the JSON documents in an Amazon S3 bucket. Create an AWS Lambda function that runs the Python code to process the documents as they arrive in the S3 bucket. Store the results in an Amazon Aurora DB cluster. This solution is highly available because Lambda functions are automatically scaled up or down based on the number of requests they receive. It is also scalable because you can easily add more Lambda functions to process more documents. Finally, it minimizes operational overhead because you do not need to manage any EC2 instances.
Comment: Using Lambda eliminates the need to manage and provision servers, ensuring scalability and minimizing operational overhead. S3 provides durable and highly available storage for the JSON documents. Lambda can be triggered automatically whenever new documents are added to the S3 bucket, allowing for real-time processing. Storing the results in an Aurora DB cluster ensures high availability and scalability for the processed data. This solution leverages serverless architecture, allowing for automatic scaling and high availability without the need for managing infrastructure, making it the most suitable choice. A. This option requires manual management and scaling of EC2 instances, resulting in higher operational overhead and complexity. C. This approach still involves manual management and scaling of EC2 instances, increasing operational complexity and overhead. D. This solution requires managing and scaling an ECS cluster, adding operational overhead and complexity. Utilizing SQS adds complexity to the system, requiring custom handling of message consumption and processing in the Python code.
Comment: Keywords here are : "maximizes scalability and minimizes operational overhead, hence option B is correct answer.
Comment: i vote for D as 'on-premises SQL database' is not mysql/postgre which can replace by aurora
Comment: Why not? It's a "SQL database", NOT necessarily Microsoft SQL Server. But even if it would be SQL server, that could be migrated to Aurora.
Comment: B is the best option. https://aws.amazon.com/rds/aurora/
Comment: agree...B is the best option S3, Lambda , Aurora.
Comment: Choosing B as "The company needs a highly available solution that maximizes scalability and minimizes operational overhead"
Comment: If you see HPC and Linux both in the question.. Pick Amazon FSx for Lustre
Comment: yeap, you're right!
Comment: Additional keywords: make data available for processing by all EC2 instances ==> FSx In absence of EFS, it should be FSx. Amazon FSx For Lustre provides a high-performance, parallel file system for hot data
Comment: Ans A - HPC so its FSx and Lustre
Comment: A is the answer because Amazon FSx for Lustre provides a high-performance, scalable file system optimized for compute-intensive workloads like HPC.
Comment: Lustre is default when HPC is involved. https://aws.amazon.com/fsx/lustre/ B: mentions Windows and no-one asked for it. C: S3 Glacier is too slow for HPC D: I don't think this is possible, unless I'm mistake, how can you connect a VPC endpoint to EBS without an EC2 kind of instance?
Comment: HPC workloads running on Linux = Amazon FSx for Lustre
Comment: High performance - Lustre
Comment: The reasons are: Amazon FSx for Lustre provides a high-performance, scalable file system optimized for compute-intensive workloads like HPC. It has native integration with Amazon S3. Data can be copied from on-premises to an S3 bucket, acting as persistent long-term storage. The FSx for Lustre file system can then access the S3 data for high speed processing of datasets and output files. FSx for Lustre is designed for the Linux environments used in this HPC workload.
Comment: FSx for Lustre is a high-performance file system optimized for compute-intensive workloads. It provides scalable, parallel access to data and is suitable for HPC applications. By integrating FSx for Lustre with S3, you can easily copy on-premises data to long-term persistent storage in S3, making it available for processing by EC2 instances. S3 serves as the durable and highly scalable object storage for storing the output files, allowing for analytics and long-term future use. Option B, FSx for Windows File Server, is not suitable because the workloads run on Linux, and this option is designed for Windows file sharing. Option C, S3 Glacier integrated with EBS, is not the best choice as it is a low-cost archival storage service and not optimized for high-performance file system requirements. Option D, using an S3 bucket with a VPC endpoint integrated with an Amazon EBS General Purpose SSD (gp2) volume, does not provide the required high-performance file system capabilities for HPC workloads.
Comment: Option A is right answer.
Comment: FSx for Lustre makes it easy and cost-effective to launch and run the popular, high-performance Lustre file system. You use Lustre for workloads where speed matters, such as machine learning, high performance computing (HPC), video processing, and financial modeling. Amazon Fsx for Lustre is integrated with Amazon S3.
Comment: Amazon FSx for Lustre integrated with Amazon S3
Comment: A is right choice here.
Comment: Option A is the best high performance storage with integration to S3
Comment: requirement is File System and workload running on linux. so S3 and FSx for windows is not an option
Comment: A The Amazon FSx for Lustre service is a fully managed, high-performance file system that makes it easy to move and process large amounts of data quickly and cost-effectively. It provides a fully managed, cloud-native file system with low operational overhead, designed for massively parallel processing and high-performance workloads. The Lustre file system is a popular, open source parallel file system that is well-suited for a variety of applications such as HPC, image processing, AI/ML, media processing, data analytics, and financial modeling, among others. With Amazon FSx for Lustre, you can quickly create and configure new file systems in minutes, and easily scale the size of your file system up or down
Comment: A is correct
Comment: AWS Fargate
Comment: A is minimal overhead. B has EC2 overhead C EC2 instance overhead + container repository running on EC2 overhead D AMII, CloudWatch alarm is overhead++
Comment: Also, simply speaking, if the company is unsure how to manage deployed containers then Fargate is the only choice.
Comment: Ans A - AWS Fargate - it does it all
Comment: fargate is the compute managed for you.. A
Comment: ECR+ECS+Fargate = Less overhead
Comment: ECR+ECS+Fargate = Less overhead
Comment: Fargate
Comment: Highly available architecture that minimizes operational overhead = Severless = Elastic Container Registry, Amazon Elastic Container Service with AWS Fargate launch type
Comment: Using ECR provides a fully managed container image registry. ECS with Fargate launch type allows running containers without managing servers or clusters. Fargate will handle scaling and optimization. Target tracking autoscaling will allow automatically adjusting capacity based on demand. The serverless approach with Fargate minimizes operational overhead.
Comment: AWF Fargate should be the best chonice
Comment: A is the right answers undoubtedly.
Comment: ECR provides a secure and scalable repository to store and manage container images. ECS with the Fargate launch type allows you to run containers without managing the underlying infrastructure, providing a serverless experience. Target tracking in ECS can automatically scale the number of tasks or services based on a target value such as CPU or memory utilization, ensuring that the application can handle increasing demand without manual intervention. Option B is not the best choice because using the EC2 launch type requires managing and scaling EC2 instances, which increases operational overhead. Option C is not the optimal solution as it involves managing the container repository on an EC2 instance and manually launching EC2 instances, which adds complexity and operational overhead. Option D also requires managing EC2 instances, configuring ASGs, and setting up manual scaling rules based on CloudWatch alarms, which is not as efficient or scalable as using Fargate in combination with ECS.
Comment: Nice exlanations!
Comment: ECS + Fargate satisfy requirements, hence option A is the best solution.
Comment: minimize operational overhead = Serverless Fargate is Serverless
Comment: Correct is "A"
Comment: You can place Fargate launch type all in one AZ, or across multiple AZs.But Option A does not take care of High Availability requirement of question. With Option C we have multi AZ.
Comment: that was my doubt too, is Fargate by default highly available? I chose D as option C didnt have a scalability option in it, option D has an autoscaling group in it C doesnt
Comment: A Why ? Because fargate provisioned on demand resource
Comment: Amazon SQS supports dead-letter queues (DLQ), which other queues (source queues) can target for messages that can't be processed (consumed) successfully. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html
Comment: Ans C - Use SQS and dead letter queue. Not ideal because max visibility timeout for SQS is 12h and can't extended by user. I did consider B: KInesis which is for real-time processing - altho' the question doesn't say its not real-time. Anyway, SQS is basic and fits.
Comment: C) This option works. There is a 12h maximum visibility timeout, but: "If you don't know how long it takes to process a message, create a heartbeat for your consumer process: Specify the initial visibility timeout (for example, 2 minutes) and then—as long as your consumer still works on the message—keep extending the visibility timeout by 2 minutes every minute." https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/working-with-messages.html
Comment: None of the options fit. A) Not operationally efficient B) Kinesis is for real-time processing D) SNS is not suitable for work queuing. C) While this may be the "correct" answer, it also doesn't really fit the problem statement. Maximum visibility timeout for SQS is 12h, also can't be extended by the consumer. "If your consumer needs longer than 12 hours, consider using Step Functions." https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
Comment: It doesn't seem to be the case though: " For example, assume that a message spends 1 day in the original queue before it's moved to a dead-letter queue. If the dead-letter queue's retention period is 4 days, the message is deleted from the dead-letter queue after 3 days and the ApproximateAgeOfOldestMessage is 3 days." https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#understanding-message-retention-periods
Comment: C is the only option with dead letter que which meets the requirement of retaining messages that fail to process without impacting other messages.
Comment: Implement an AWS service to handle messages between the two applications = Amazon Simple Queue Service If the messages fail to process, they must be retained = a dead-letter queue
Comment: SQS provides a fully managed message queuing service that meets all the requirements: SQS can handle the sending and processing of 1,000 messages per hour Messages can be retained for up to 14 days to allow the full 2 days for processing Using a dead-letter queue will retain failed messages without impacting other processing SQS requires minimal operational overhead compared to running your own message queue server
Comment: Answer is B), the reason is: - Because messages might up to 2 days to be processed. Visibility timeout of SQS is 12 hours, so after 12 hours another consumer might take a message from the queue which is currently being processed.
Comment: By integrating both the sender and processor applications with an SQS, messages can be reliably sent from the sender to the processor application for processing. SQS provides at-least-once delivery, ensuring that messages are not lost in transit. If a message fails to process, it can be retained in the queue and retried without impacting the processing of other messages. Configuring a DLQ allows for the collection of messages that repeatedly fail to process, providing visibility into failed messages for troubleshooting and analysis. A is not the optimal choice as it involves managing and configuring an EC2 instance running a Redis, which adds operational overhead and maintenance requirements. B is not the most operationally efficient solution as it introduces additional complexity by using Amazon Kinesis data streams and integrating with the Kinesis Client Library for message processing. D, using SNS, is not the best fit for the scenario as it is more suitable for pub/sub messaging and broadcasting notifications rather than the specific requirement of message processing between two applications.
Comment: Nice exlanations always, thanks a lot!
Comment: Nice explanations always, thanks a lot
Comment: Answer C, In Question if Keyword have Processing Failed >> SQS
Comment: solution that meets these requirements and is the MOST operationally efficient will be option C. SQS is buffer between 2 APPs.
Comment: The visibility timeout must not be more than 12 hours. ( For SQS ) Jobs may take 2 days to process
Comment: operationally efficient = Serverless SQS is serverless
Comment: SNS too is serverless, but it is obvious that it is not the correct answer in this case
Comment: more realistic option is C. only problem with this is the limit of the visibility timeout is 12H max. as the second application take 2 days to process, there will be a duplicate of processing messages in the queue. this might complicate things.
Comment: Amazon SQS automatically deletes messages that have been in a queue for more than the maximum message retention period. The default message retention period is 4 days. However, you can set the message retention period to a value from 60 seconds to 1,209,600 seconds (14 days) using the SetQueueAttributes action. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html
Comment: SQS has a limit 12h for visibility time out
Comment: Option C, using Amazon SQS, is a valid solution that meets the requirements of the company. However, it may not be the most operationally efficient solution because SQS is a managed message queue service that requires additional operational overhead to handle the retention of messages that failed to process. Option B, using Amazon Kinesis Data Streams, is more operationally efficient for this use case because it can handle the retention of messages that failed to process automatically and provides the ability to process and analyze streaming data in real-time.
Comment: Kinesis stream save data for up to 24 hours, doesn't meet the 2 day requirement. Kinesis streams don't have fail-safe for failed processing, unlike SQS. The correct answer is C - SQS.
Comment: this is not a correct statement. A data stream is a logical grouping of shards. There are no bounds on the number of shards within a data stream (request a limit increase if you need more). A data stream will retain data for 24 hours by default, or optionally up to 365 days. Shard https://aws.amazon.com/kinesis/data-streams/getting-started/
Comment: There's no way for kinesis to know whether the message processing failed.
Comment: Option C.
Comment: Answer D. Use an OAI to lockdown CloudFront to S3 origin & enable WAF on CF distribution
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-access-to-amazon-s3/ confirms use of OAI (and option D).
Comment: By configuring CloudFront to forward all incoming requests to AWS WAF, the traffic will be inspected by AWS WAF before reaching the S3 origin, complying with the security policy requirement. This approach ensures that all website traffic is inspected by AWS WAF, providing an additional layer of security before accessing the content stored in the S3 origin. Option A is not the correct choice as configuring an S3 bucket policy to accept requests from the AWS WAF ARN only would bypass the inspection of traffic by AWS WAF. It does not ensure that all website traffic is inspected. Option C is not the optimal solution as it focuses on controlling access to S3 using a security group. Although it associates AWS WAF with CloudFront, it does not guarantee that all incoming requests are inspected by AWS WAF. Option D is not the recommended solution as configuring an OAI in CloudFront and restricting access to the S3 bucket does not ensure that all website traffic is inspected by AWS WAF. The OAI is used for restricting direct access to S3 content, but the traffic should still pass through AWS WAF for inspection.
Comment: Option B does use the WAF through Cloudfront, but it does not mention anything to prevent direct access to the objects without going through Cloudfront.
Comment: Apparently you can only point to a custom host that is "not an Amazon Simple Storage Service (Amazon S3) bucket" (other than for static hosting). https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/. Answer should be D
Comment: agreed. Must be D as per above security blog
Comment: Ans B - configure CloudFront to forward incoming requests to AWS WAF for inspection before sending to S3. This provides an additional layer of security before accessing the content stored in the S3 origin. D: not ideal because configuring an OAI in CloudFront and restricting access to the S3 bucket does not guarantee website traffic is inspected by WAF.
Comment: B is incorrect , it misrepresents how AWS WAF works with CloudFront. AWS WAF is not an intermediary service that CloudFront forwards requests to. Instead, AWS WAF is directly integrated with CloudFront as a layer to inspect incoming requests. The correct configuration is to associate AWS WAF with the CloudFront distribution, not to forward requests separately.
Comment: Cloud Front allows configuration to enable AWS WAF and restrict direct access to S3 through OAI will meet the requirenments.
Comment: The requirements indicate that S3 is used to "store" a static website, not that it must be configured as a static website (which does not make any sense if it's to be used with CF anyway). Furthermore, the requirements also indicate that all traffic must be inspected by WAF. If you do not setup OAI/OAC, you can potentially bypass CF and access S3 directly. So option B does not satisfy the second requirement.
Comment: Using an OAI (Origin Access Identity) restricts access to the S3 bucket, ensuring that only CloudFront can access the content. Enabling AWS WAF on the CloudFront distribution allows you to inspect website traffic and filter out malicious requests before they reach your S3 origin.
Comment: OAI is required so that S3 bucket is not accessed directly.
Comment: I guess D
Comment: There are two ways you can serve static websites on AWS S3 origin, either using website endpoints or REST API endpoints. Website endpoints does not support HTTPS. Note that the question does not mention which endpoint is used. https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html#WebsiteRestEndpointDiff B is incorrect because we do not 'forward' requests to AWS WAF, we attach WAF on the Cloudfront distribution itself. Could be bad wording of the question. D is totally valid because it doesn't mention using website endpoints. D also uses OAI to restrict direct access to objects in AWS S3. Although OAI is still viable in this point of time, it is still a legacy method and it is more recommended to use OAC instead. https://repost.aws/knowledge-center/cloudfront-serve-static-website
Comment: Option B ensures that all incoming requests to the static website served through Amazon CloudFront are first forwarded to AWS WAF for inspection before the content is requested from the S3 origin. This ensures that all website traffic is inspected by AWS WAF as required by the company's security policy.
Comment: D is not possible since you cannot set OAC or OAI if S3 bucket is used as static website host
Comment: WAF is associated to a Cloudfront Distribution
Comment: A: Doesn't make sense in context with CF. B: You configure WAF on CF for HTTP status handling so this may be right be is badly worded C: You might as well re-engineer S3 and CloudFront! D: The requirement for WAF usage is met with this. Doesn't have to be smart usage, just enabled.
Comment: some people use below link as supported point, but when you look into link, AWF is in front of CloudFront from traffic view. So, B is incorrect because 'there is no CloudFront forward requesting to ACL.' https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/
Comment: A content delivery network is typically deployed before a web application firewall (WAF). Refer to the "Here's how the solution works" section provided in your linked resource.
Comment: B. Configure Amazon CloudFront to forward all incoming requests to AWS WAF before requesting content from the S3 origin. This option ensures that all website traffic passes through AWS WAF for inspection before reaching the S3 origin, complying with the security policy requirements. I appreciate your thorough analysis.
Comment: It's storage, not web endpoint.so It's http://[bucket-name].s3.[region].amazonaws.com ，and oai can be used
Comment: The most effective and efficient solution would be Option D (Use Amazon CloudFront with the S3 bucket as its origin.) Amazon CloudFront is a content delivery network (CDN) that speeds up the delivery of static and dynamic web content, such as HTML pages, images, and videos. By using CloudFront, the HTML pages will be served to users from the edge location that is closest to them, resulting in faster delivery and a better user experience. CloudFront can also handle the high traffic and large number of requests expected for the global event, ensuring that the HTML pages are available and accessible to users around the world.
Comment: Global users = Amazon CloudFront
Comment: CloudFront is the best solution for this use case because: CloudFront is a content delivery network (CDN) that caches content at edge locations around the world. This brings content closer to users for fast performance. For high traffic global events with millions of viewers, a CDN is necessary for effective distribution. Using the S3 bucket as the origin, CloudFront can fetch the files once and cache them globally.
Comment: CloudFront is well-suited for efficiently serving static HTML pages to users around the world. By using itwith the S3 as its origin, the static HTML pages can be cached and distributed globally to edge locations, reducing latency and improving performance for users accessing the pages from different regions. This solution ensures efficient and effective delivery of the daily reports to millions of users worldwide, providing a scalable and high-performance solution for the global event. A would allow temporary access to the files, but it does not address the scalability and performance requirements of serving millions of views globally. B is not necessary for this scenario as the goal is to distribute the static HTML pages efficiently to users worldwide, not replicate the files across multiple Regions. C is primarily used for routing DNS traffic based on the geographic location of users, but it does not provide the caching and content delivery capabilities required for this use case.
Comment: Option D
Comment: Agreed
Comment: answer is D agree with Shasha1
Comment: D CloudFront is a content delivery network (CDN) offered by Amazon Web Services (AWS). It functions as a reverse proxy service that caches web content across AWS's global data centers, improving loading speeds and reducing the strain on origin servers. CloudFront can be used to efficiently deliver large amounts of static or dynamic content anywhere in the world.
Comment: D is correct
Comment: D Static content on S3 and hence Cloudfront is the best way
Comment: D is the correct answer
Comment: "without any downtime" - Reserved Instances for the baseline capacity "MOST cost-effectively" - Spot Instances to handle additional capacity
Comment: Dude, read the question, cost consideration was not mentioned in the question.
Comment: Dude, read the question, "Which solution meets these requirements MOST cost-effectively?"
Comment: I am leaning towards C because the idea of having a queue is to decouple the processing. If an instance goes down(spot) while processing will it not show up back after the visibility timeout? So using spot meets the cost-effective objective.
Comment: Intermediate data stored in SQS queue so once free then it take data and process.
Comment: cost-effectively means, Cheapest solution (cost) that achieve all the requirements (effectively). Its not cost-effectively if is just cheapest solution that fail to address all the requirements, in this case. (This application should continually process messages without any downtime) no matter the volume, since it is unpredictable. B for example, address the requirement but not the cheapest solution that achieve it. D is the cheaper choice that address the requirement (without any downtime). and C is cheaper than D but do not garantee that you wont have downtime since it is SPOT instances.
Comment: How can you have baseline capacity when your message volume is unpredictable and often has intermittent traffic?
Comment: For this reason I think correct answer is A
Comment: Spot instances cannot be an option as it is unreliable and the question requires the messages to be continuously processed
Comment: D is the correct answer
Comment: C is correct, read for cost effectiveness
Comment: AWS has stopped issuing spot instances so i think C
Comment: so i think C is incorrect*. the Correct ans is D.
Comment: if you cannot find enough spot instance you will have downtime you cannot always find spot instance
Comment: Why downtime when there are baseline reserved instances?
Comment: When traffic spikes and there happens to an increase in the spot price, if the price exceeds the threshold set then there would be downtime as no additional compute can be acquired. Hence even if spot instances are more cost effective, I would interpret the cost effective requirement to be the ability to reliably acquire new instances and dispose of when not needed, hence on demand instances
Comment: First we need to ensure that no downtime. Then we can talk about cost-effective.
Comment: without any downtime... this imediately exclude spot instances...
Comment: I think it is D, because NOWHERE is mentioned that it should be the most cost effective scenario. It is mentioned that it must process messages without any downtime.
Comment: it LITERALLY says: "Which solution meets these requirements MOST cost-effectively?"
Comment: "without any downtime" - Reserved Instances for the baseline capacity "MOST cost-effectively" - Spot Instances to handle additional capacity
Comment: C is definitely the most cost-effective, also the application shouldn't face any downtime because of the reserved instances always running.
Comment: Dude without downtime - spot instances might interrupt the processing if it goes away. So correct answer is D
Comment: C for sure
Comment: Reserved Instances (RIs) provide a cost-effective way to cover the baseline capacity, ensuring a predictable number of instances are always available. Spot Instances can handle additional capacity during traffic spikes, providing scalability without committing to a specific number of instances. This combination (C) offers the most cost-effective solution, as RIs cover the baseline and Spot Instances handle variable demand. Why not D? On demand is expensive than Spot instances.
Comment: If it is a spot instance, it may become unusable. Since the question states that there is no downtime, I think D is more in line with the purpose.
Comment: key word - production System & without any down time. This excludes spot instance.
Comment: C is correct because MOST cost-effective reason
Comment: Using Reserved Instances (RIs) for baseline capacity ensures a lower cost for the instances that are constantly required to maintain the application's baseline workload. RIs offer significant cost savings compared to On-Demand instances, making them a cost-effective choice for steady-state workloads. Spot Instances can then be utilized to handle additional capacity during periods of higher message volume. Spot Instances provide spare EC2 capacity at significantly reduced prices compared to On-Demand instances, allowing for cost savings during peak workloads. Since the message volume is unpredictable and often intermittent, Spot Instances can efficiently handle the fluctuating demand without incurring high costs.
Comment: Missing some information to make a proper decision. What does "without downtime" mean? We are already outside of Realtime processing, and messages can remain in the queue until picked up. Purely using Spot instances _might_ do just fine, but there could be times when no spare capacity is available. How much delay is acceptable? I'd go with reserved+spot, but reserved+on demand may be required for priority on bursty load. B is the one option i would rule out completely. The workload is unpredictable, we can't reserve infinity instances for all eternity.
Comment: Keywords are - Production, without any downtime. I would prefer D option as AWS itself recommends, spot instances should not be used in Prod environment.
Comment: I think this phrase "This application should continually process messages without any downtime." killed the idea of using Spot instances, not 100% sure though.
Comment: D. Service control policies (SCPs) are one type of policy that you can use to manage your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization's access control guidelines. See https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html.
Comment: By creating an SCP in the root organizational unit, the security team can define and enforce fine-grained permissions that limit access to specific services or actions across all member accounts. The SCP acts as a guardrail, denying access to specified services or actions, ensuring that the permissions are consistent and applied uniformly across the organization. SCPs are scalable and provide a single point of control for managing permissions, allowing the security team to centrally manage access restrictions without needing to modify individual account settings. Option A and option B are not suitable for controlling access across multiple accounts in AWS Organizations. ACLs and security groups are typically used for managing network traffic and access within a single account or a specific resource. Option C is not the recommended approach. Cross-account roles are used for granting access, and denying access through cross-account roles can be complex and less manageable compared to using SCPs.
Comment: This was a good explanation of why A and B are not correct. I was thinking A but after reading this I agree with you D is correct.
Comment: D. Service control policies (SCPs) are one type of policy that you can use to manage your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization's access control guidelines. See https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html.
Comment: is D because of Deeznuts
Comment: gottem
Comment: Its very clear question answer is D
Comment: https://medium.com/@darekhale91/how-to-pass-amazon-saa-c03-exam-dumps-2023-583619ddbcc8
Comment: Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization's access control guidelines.
Comment: D. Service control policies (SCPs) are one type of policy that you can use to manage your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization's access control guidelines. See https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html.
Comment: I vote for option D by Creating a service control policy ( SCP) in the root organizational unit to deny access to the services or actions, meets the requirements.
Comment: To limit access to specific services or actions in all of the team's AWS accounts and maintain a single point where permissions can be managed, the solutions architect should create a service control policy (SCP) in the root organizational unit to deny access to the services or actions (Option D). Service control policies (SCPs) are policies that you can use to set fine-grained permissions for your AWS accounts within your organization. SCPs are attached to the root of the organizational unit (OU) or to individual accounts, and they specify the permissions that are allowed or denied for the accounts within the scope of the policy. By creating an SCP in the root organizational unit, the security team can set permissions for all of the accounts in the organization from a single location, ensuring that the permissions are consistently applied across all accounts.
Comment: Option D
Comment: D iscorrect
Comment: an organization and requires single point place to manage permissions
Comment: SCP for organization
Comment: What's going on, suddenly the questions are so easy
Comment: Its due to confidence level going up after experience.
Comment: When you see DDOS immediately think Shield
Comment: When you see DDOS immediately think Shield
Comment: AWS Shield is a managed DDoS protection service that safeguards applications running on AWS.
Comment: Enable AWS Shield Advanced to prevent attacks.
Comment: By enabling Shield Advanced, the web application benefits from automatic protection against common and sophisticated DDoS attacks. It utilizes advanced detection and mitigation techniques, including ML algorithms and traffic analysis, to provide effective DDoS protection. It also includes features like real-time monitoring, attack notifications, and detailed attack reports. A is not related to DDoS protection. Amazon Inspector is a security assessment service that helps identify vulnerabilities and security issues in applications and EC2. B is also not the appropriate solution. Macie is a service that uses machine learning to discover, classify, and protect sensitive data stored in AWS. It focuses on data security and protection, not specifically on DDoS prevention. D is not the most effective solution. GuardDuty is a threat detection service that analyzes events and network traffic to identify potential security threats and anomalies. While it can provide insights into potential DDoS attacks, it does not actively prevent or mitigate them.
Comment: Explained in details here https://medium.com/@tshemku/aws-waf-vs-firewall-manager-vs-shield-vs-shield-advanced-4c86911e94c6
Comment: To reduce the risk of DDoS attacks against the application, the solutions architect should enable AWS Shield Advanced (Option C). AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that helps protect web applications running on AWS from DDoS attacks. AWS Shield Advanced is an additional layer of protection that provides enhanced DDoS protection capabilities, including proactive monitoring and automatic inline mitigations, to help protect against even the largest and most sophisticated DDoS attacks. By enabling AWS Shield Advanced, the solutions architect can help protect the application from DDoS attacks and reduce the risk of disruption to the application.
Comment: C is right answer
Comment: C is correct
Comment: AWS Shield Advanced
Comment: DDOS = AWS Shield
Comment: Geographic (Geo) Match Conditions in AWS WAF. This new condition type allows you to use AWS WAF to restrict application access based on the geographic location of your viewers. With geo match conditions you can choose the countries from which AWS WAF should allow access. https://aws.amazon.com/about-aws/whats-new/2017/10/aws-waf-now-supports-geographic-match/
Comment: C --> One of the feature of WAF is Access Control: Implement IP whitelisting and blacklisting to allow or block traffic from specific IP addresses or address ranges. This can be useful for restricting access to your web application to trusted users or regions.
Comment: Geographic (Geo) Match Conditions in AWS WAF. This new condition type allows you to use AWS WAF to restrict application access based on the geographic location of your viewers. With geo match conditions you can choose the countries from which AWS WAF should allow access. https://aws.amazon.com/about-aws/whats-new/2017/10/aws-waf-now-supports-geographic-match/
Comment: C. Configure AWS WAF on the Application Load Balancer in a VPC
Comment: We can use AWS WAF to configure access control rule to access from specific location.
Comment: By configuring AWS WAF on the ALB in a VPC, you can apply access control rules based on the geographic location of the incoming requests. AWS WAF allows you to create rules that include conditions based on the IP addresses' country of origin. You can specify the desired country and deny access to requests originating from any other country by leveraging AWS WAF's Geo Match feature. Option A and option B focus on network-level access control and do not provide country-specific filtering capabilities. Option D is not the ideal solution for restricting access based on country. Network ACLs primarily control traffic at the subnet level based on IP addresses and port numbers, but they do not have built-in capabilities for country-based filtering.
Comment: Configure AWS WAF for Geo Match Policy
Comment: Source from an AWS link Geographic (Geo) Match Conditions in AWS WAF. This condition type allows you to use AWS WAF to restrict application access based on the geographic location of your viewers. With geo match conditions you can choose the countries from which AWS WAF should allow access.
Comment: WAF Shield Advanced for DDOS, GuardDuty is a continuous monitoring service that alerts you of potential threats, while Inspector is a one-time assessment service that provides a report of vulnerabilities and deviations from best practices.
Comment: To meet the requirement of allowing the web application to be accessed from one specific country only, the company should configure AWS WAF (Web Application Firewall) on the Application Load Balancer in a VPC (Option C). AWS WAF is a web application firewall service that helps protect web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF allows you to create rules that block or allow traffic based on the values of specific request parameters, such as IP address, HTTP header, or query string value. By configuring AWS WAF on the Application Load Balancer and creating rules that allow traffic from a specific country, the company can ensure that the web application is only accessible from that country.
Comment: OptionC. Configure WAF for Geo Match Policy
Comment: C is correct
Comment: C https://aws.amazon.com/about-aws/whats-new/2017/10/aws-waf-now-supports-geographic-match/
Comment: C. WAF with ALB is the right option
Comment: Option D is similar to option B in that it uses Amazon API Gateway to handle the API requests, but it also includes an EC2 instance to perform the tax computations. However, using an EC2 instance in this way is less scalable and less elastic than using AWS Lambda to perform the computations. An EC2 instance is a fixed resource and requires manual scaling and management, while Lambda is an event-driven, serverless compute service that automatically scales with the number of requests, making it more suitable for handling variable workloads and reducing response times during high traffic periods. Additionally, Lambda is more cost-efficient than EC2 instances, as you only pay for the compute time consumed by your functions, making it a more cost-effective solution.
Comment: b. easy
Comment: Option B: Lamda = scalable and elastic
Comment: Option B leverages AWS Lambda, which is a serverless compute service that automatically scales in response to incoming requests. When a request is made to the API hosted on Amazon API Gateway, API Gateway triggers the associated AWS Lambda function, passing the item names as input parameters. The Lambda function then performs the tax computations based on the provided item names. AWS Lambda automatically manages the compute capacity, ensuring that there is no need to provision or manage servers. This serverless architecture offers scalability and elasticity, as Lambda functions can scale out to handle a larger number of inquiries during the holiday season and scale in during periods of lower demand. Additionally, AWS Lambda is a fully managed service, reducing operational overhead for the company.
Comment: The thing that bothers me about B is that the request sends the name and then based on the name, the tax is calculated. How do you calculate a value e.g. tax if you just have a name...
Comment: EC2 without autoscaling is not elastic so A, C & D won't be suitable. B uses AWS Lambda which is elastic and scalable by design.
Comment: Though EC2 can scale (even if less flexible than Lambda), neither A, C nor D involve scaling. All these answers are about a single EC2 instance or a pair of EC2 instances. The only answer that includes scaling and elasticity is B.
Comment: I agree.
Comment: scalable and elastic = serverless = API gateway and AWS Lambda
Comment: in 002 answer is B. Why is that?
Comment: Options A, C, and D involve EC2 instances, which are not as inherently scalable and elastic as serverless AWS Lambda functions, and they would require more manual management and operational overhead. Therefore, option B is the most appropriate choice for a scalable and elastic API solution.
Comment: REST API using Amazon API Gateway and integrating it with AWS Lambda (option B) is the recommended approach to achieve a scalable and elastic solution for the company's API during the holiday season. ________ No good EC2 in this case using an EC2 instance in this way is less scalable and less elastic than using AWS Lambda to perform the computations
Comment: scalable and elastic = serverless = API gateway and AWS Lambda
Comment: B) Design a REST API using Amazon API Gateway that accepts the item names. API Gateway passes item names to AWS Lambda for tax computations. This option provides the most scalable and elastic solution: API Gateway handles creating the REST API frontend to receive requests Lambda functions scale automatically to handle spikes in traffic during peak seasons No servers to manage for the computations, providing high scalability
Comment: Option A (hosting an API on an Amazon EC2 instance) would require manual management and scaling of the EC2 instances, making it less scalable and elastic compared to a serverless solution. Option C (creating an Application Load Balancer with EC2 instances for tax computations) also involves manual management of the instances and does not offer the same level of scalability and elasticity as a serverless solution. Option D (designing a REST API using API Gateway and connecting it with an API hosted on an EC2 instance) adds unnecessary complexity and management overhead. It is more efficient to directly integrate API Gateway with AWS Lambda for tax computations. Therefore, designing a REST API using Amazon API Gateway and integrating it with AWS Lambda (option B) is the recommended approach to achieve a scalable and elastic solution for the company's API during the holiday season.
Comment: Option B is the solution that is scalable and elastic, hence this meets requirements.
Comment: I also prefer B over D. However, it is quite vague since the question doesn't provide the processing time. The maximum processing time for AWS Lambda is 15 minutes.
Comment: B. Serverless option wins over EC2
Comment: CCCCCCCCC Field-level encryption allows you to enable your users to securely upload sensitive information to your web servers. The sensitive information provided by your users is encrypted at the edge, close to the user, and remains encrypted throughout your entire application stack. This encryption ensures that only applications that need the data—and have the credentials to decrypt it—are able to do so.
Comment: field level encryption allow to protect sensitive information throughout the application stack
Comment: With Amazon CloudFront, you can enforce secure end-to-end connections to origin servers by using HTTPS. Field-level encryption adds an additional layer of security that lets you protect specific data throughout system processing so that only certain applications can see it. Field-level encryption allows you to enable your users to securely upload sensitive information to your web servers. The sensitive information provided by your users is encrypted at the edge, close to the user, and remains encrypted throughout your entire application stack. This encryption ensures that only applications that need the data—and have the credentials to decrypt it—are able to do so.
Comment: C: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html
Comment: C is the only one that addresses handling sensitive information.
Comment: Reviewing my first vote after research. It seems that C is the best answer: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html
Comment: A if for fetch. B requires cookies. D just enforces HTTPS which is already mentioned for the solution (CloudFront only allows HTTPS) and does not add another layer of security. C provides field level encryption security which is another layer of security.
Comment: Please go through below link: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html
Comment: This is about controlling access for downloads (making sure that the download request is coming from an authenticated user), it has nothing to do with protecting data that is sent to the application.
Comment: cccc,this link https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html
Comment: Options A and B (signed URL and signed cookie) are used for controlling access to specific resources and are typically used for restricting access based on URLs or cookies. They do not provide field-level encryption for sensitive data within HTTP requests. Option D (configuring CloudFront with the Origin Protocol Policy set to HTTPS Only for the Viewer Protocol Policy) is related to enforcing HTTPS communication between CloudFront and the viewer (end-user). While important for security, it doesn't address the specific requirement of protecting sensitive data within the application stack.
Comment: C) Configure a CloudFront field-level encryption profile. Field-level encryption allows you to encrypt sensitive information at the edge before distributing content through CloudFront. It provides an additional layer of security for sensitive user-submitted data. The other options would not provide field-level encryption
Comment: Would the HTTPS imply that the cert was signed by a CA
Comment: Option A and Option B are used for controlling access to specific resources or content based on signed URLs or cookies. While they provide security and access control, they do not provide field-level encryption for sensitive data within the requests. Option D ensures that communication between the viewer and CloudFront is encrypted with HTTPS. However, it does not specifically address the protection and encryption of sensitive information within the application stack. Therefore, the most appropriate action to protect sensitive information throughout the entire application stack and restrict access to certain applications is to configure a CloudFront field-level encryption profile (Option C).
Comment: With Amazon CloudFront, you can enforce secure end-to-end connections to origin servers by using HTTPS. Field-level encryption adds an additional layer of security that lets you protect specific data throughout system processing so that only certain applications can see it.
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html "Field-level encryption allows you to enable your users to securely upload sensitive information to your web servers. The sensitive information provided by your users is encrypted at the edge, close to the user, and remains encrypted throughout your entire application stack".
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-levelencryption. html "With Amazon CloudFront, you can enforce secure end-to-end connections to origin servers by using HTTPS. Field-level encryption adds an additional layer of security that lets you protect specific data throughout system processing so that only certain applications can see it."
Comment: C, field-level encryption should be used when necessary to protect sensitive data.
Comment: B. Cloud front is best for content delivery. Global Accelerator is best for non-HTTP (TCP/UDP) cases and supports HTTP cases as well but with static IP (elastic IP) or anycast IP address only.
Comment: CloudFront will cache the data in Edge Locations, offloading it partially from the source location (s3) B looks good to me.
Comment: Deploy an Amazon CloudFront web distribution in front of the S3 bucket
Comment: B) Deploy an Amazon CloudFront web distribution in front of the S3 bucket. CloudFront is the most cost-effective solution for this use case because: CloudFront can cache static assets like videos and images at edge locations closer to users. This improves performance. Serving files from the CloudFront cache reduces load on the S3 origin. CloudFront pricing is very low for data transfer and requests.
Comment: ElasticCache is for DB Cache(RDS) nor for S3
Comment: Option A is not the most cost-effective solution for this scenario. While Global Accelerator can improve global application performance, it is primarily used for accelerating TCP and UDP traffic, such as gaming and real-time applications, rather than serving static media files. Options C and D are used for caching frequently accessed data in-memory to improve application performance. However, they are not specifically designed for caching and serving media files like CloudFront, and therefore, may not provide the same cost-effectiveness and scalability for this use case. Hence, deploying an CloudFront web distribution in front of the S3 is the most cost-effective solution for delivering media files to millions of users worldwide while reducing the load on the origin.
Comment: ElastiCache, enhances the performance of web applications by quickly retrieving information from fully-managed in-memory data stores. It utilizes Memcached and Redis, and manages to considerably reduce the time your applications would, otherwise, take to read data from disk-based databases. Amazon CloudFront supports dynamic content from HTTP and WebSocket protocols, which are based on the Transmission Control Protocol (TCP) protocol. Common use cases include dynamic API calls, web pages and web applications, as well as an application's static files such as audio and images. It also supports on-demand media streaming over HTTP. AWS Global Accelerator supports both User Datagram Protocol (UDP) and TCP-based protocols. It is commonly used for non-HTTP use cases, such as gaming, IoT and voice over IP. It is also good for HTTP use cases that need static IP addresses or fast regional failover
Comment: The company wants to provide the files to the users while reducing the load on the origin. Cloudfront speeds-up content delivery but I'm not sure it reduces the load on the origin. Some form of caching would cache content and deliver to users without going to the origin for each request.
Comment: CloudFront's only main purpose is to serve these kind of scenarios!
Comment: "Some form of caching would cache content and deliver to users without going to the origin for each request", isn't this EXACTLY what CloudFront does?
Comment: ElastiCache for Redis (C) can be used by an application to store key-value pairs. It does not cache videos or images and it is not an automatic process (the application can put and retrieve values).
Comment: To provide media files to users while reducing the load on the origin and meeting the requirements cost-effectively, the gaming company should deploy an Amazon CloudFront web distribution in front of the S3 bucket (Option B). CloudFront is a content delivery network (CDN) that speeds up the delivery of static and dynamic web content, such as images and videos, to users. By using CloudFront, the media files will be served to users from the edge location that is closest to them, resulting in faster delivery and a better user experience. CloudFront can also handle the high traffic and large number of requests expected from the millions of users, ensuring that the media files are available and accessible to users around the world.
Comment: Please dont post ChatGPT answers here,chatgpt keeps on changing its answers,its not the right way to copy paste,thanks.
Comment: Woaaaa! I always wondered where this kind of logic and explanation came from in this guy's answers. Nice catch TECHHB!
Comment: Answers are mostly correct. Only a small percentage were wrong
Comment: why not? if the answers are correct and offer best possible explanation for the wrong options, I see no reason why it shouldn't be posted here. Also, most of his answers were right, although reasons for the wrong options were sometimes lacking, but all in all, his responses were very good.
Comment: Option B
Comment: Agreed
Comment: B is the correct answer
Comment: B is correct
Comment: B. auto scaling groups can not span multi region
Comment: Option A (creating an Auto Scaling group across two Regions) introduces additional complexity and potential replication challenges, which may not be necessary for achieving high availability within a single Region. Option C (creating an Auto Scaling template for another Region) suggests multi-region redundancy, which may not be the most straightforward solution for achieving high availability without modifying the application. Option D (changing the ALB to a round-robin configuration) does not provide the desired high availability. Round-robin configuration alone does not ensure fault tolerance and does not leverage multiple Availability Zones for resilience. Hence, modifying the Auto Scaling group to use three instances across each of two Availability Zones is the appropriate choice to provide high availability for the multi-tier application.
Comment: Modify the Auto Scaling group to use three instances across each of two Availability Zones
Comment: Option B. Modify the Auto Scaling group to use three instances across each of the two Availability Zones.
Comment: B. auto scaling groups cannot span multi region
Comment: Option B. Modify the Auto Scaling group to use three instances across each of the two Availability Zones. This option would provide high availability by distributing the front-end web servers across multiple Availability Zones. If there is an issue with one Availability Zone, the other Availability Zone would still be available to serve traffic. This would ensure that the application remains available and highly available even if there is a failure in one of the Availability Zones.
Comment: Option B
Comment: Agreed
Comment: B option B This architecture provides high availability by having multiple Availability Zones hosting the same application. This allows for redundancy in case one Availability Zone experiences downtime, as traffic can be served by the other Availability Zone. This solution also increases scalability and performance by allowing traffic to be spread across two Availability Zones.
Comment: B is rightt
Comment: B is correct
Comment: B auto scaling i multiple AZ
Comment: Many applications, including those built on modern serverless architectures, can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability. https://aws.amazon.com/id/rds/proxy/
Comment: Are you sure?
Comment: Option A (configuring provisioned concurrency and creating a global database) does not directly address the high connection utilization issue on the database, and creating a global database may introduce additional complexity without immediate benefit to solving the timeout errors. Option C (creating a read replica in a different AWS Region) introduces additional data replication and management complexity, which may not be necessary to address the timeout errors. Option D (migrating to Amazon DynamoDB) involves a significant change in the data storage technology and requires modifying the application to use DynamoDB instead of Aurora PostgreSQL. This may not be the most suitable solution when the goal is to make minimal changes to the application. Therefore, using Amazon RDS Proxy and modifying the Lambda function to use the RDS Proxy endpoint is the recommended solution to prevent timeout errors and reduce the impact on the database during peak loads.
Comment: Amazon RDS Proxy is a fully managed, highly available database proxy for Amazon Relational Database Service (RDS) that makes applications more scalable, more resilient to database failures, and more secure. B
Comment: Connection problems causing high CPU and Memory usage? Use RDS proxy!
Comment: Improving database efficiency by reducing the stress on database resources (e.g., CPU, RAM) and minimize open connections (and timeouts).
Comment: Use Amazon RDS Proxy to create a proxy for the database. Modify the Lambda function to use the RDS Proxy endpoint instead of the database endpoint.
Comment: using Amazon RDS Proxy and modifying the Lambda function to use the RDS Proxy endpoint is the recommended solution to prevent timeout errors and reduce the impact on the database during peak loads.
Comment: I also think the answer is B. However can RDS Proxy be used with Amazon Aurora PostgreSQL database?
Comment: RDS Proxy can be used with Aurora https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: I expect a answer with database replica but there is not, so B is most suitable
Comment: Option B. Use Amazon RDS Proxy to create a proxy for the database. Modify the Lambda function to use the RDS Proxy endpoint instead of the database endpoint. Using Amazon RDS Proxy can help reduce the number of connections to the database and improve the performance of the application. RDS Proxy establishes a connection pool to the database and routes connections to the available connections in the pool. This can help reduce the number of open connections to the database and improve the performance of the application. The Lambda function can be modified to use the RDS Proxy endpoint instead of the database endpoint to take advantage of this improvement.
Comment: Option A is not a valid solution because configuring provisioned concurrency for the Lambda function does not address the issue of high CPU utilization and memory utilization on the database. Option C is not a valid solution because creating a read replica in a different Region does not address the issue of high CPU utilization and memory utilization on the database. Option D is not a valid solution because migrating the data from Aurora PostgreSQL to DynamoDB would require significant changes to the application and may not be the best solution for this particular problem.
Comment: Option --- B
Comment: As it is mentioned that issue was due to high CPU and Memory due to many open corrections to DB, B is the right answer.
Comment: B Using Amazon RDS Proxy will allow the application to handle more connections and higher loads without timeouts, while making the least possible changes to the application. The RDS Proxy will enable connection pooling, allowing multiple connections from the Lambda function to be served from a single proxy connection. This will reduce the number of open connections on the database, which is causing high CPU and memory utilization
Comment: B is correct
Comment: B - Proxy to manage connections
Comment: Issue related to opening many connections and the solution requires least code changes so B satisfies the conditions
Comment: Correct B
Comment: VPC endpoints for service in private subnets https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html
Comment: Option B (using a NAT gateway in a public subnet) and option C (using a NAT instance in a private subnet) are not the most secure options because they involve routing traffic through a network address translation (NAT) device, which requires an internet gateway and traverses the public internet. Option D (using the internet gateway attached to the VPC) would require routing traffic through the internet gateway, which would result in the traffic leaving the AWS network. Therefore, the recommended and most secure approach is to use a VPC endpoint for DynamoDB to ensure private and secure access to the DynamoDB table from your EC2 instances in private subnets, without the need to traverse the internet or leave the AWS network.
Comment: Using an internet gateway (Option D) is used for enabling outbound internet connectivity from resources in your VPC. It's not the appropriate choice for securely accessing DynamoDB within your VPC.
Comment: A gateway VPC Endpoint is designed for supported AWS service such as dynamo db or s3 in this case i assume the endpoint is still the valid option
Comment: Use a VPC endpoint for DynamoDB. A VPC endpoint enables customers to privately connect to supported AWS services: Amazon DynamoDB or Amazon Simple Storage Service (Amazon S3).
Comment: A VPC endpoint enables private connectivity between VPCs and AWS services without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect. Traffic remains within the AWS network.
Comment: VPC endpoints for service in private subnets
Comment: VPC endpoint for dynamodb and S3
Comment: VPC endpoints for DynamoDB can alleviate these challenges. A VPC endpoint for DynamoDB enables Amazon EC2 instances in your VPC to use their private IP addresses to access DynamoDB with no exposure to the public internet. Your EC2 instances do not require public IP addresses, and you don't need an internet gateway, a NAT device, or a virtual private gateway in your VPC. You use endpoint policies to control access to DynamoDB. Traffic between your VPC and the AWS service does not leave the Amazon network.
Comment: AAAAAAAAA
Comment: Option A: Use a VPC endpoint for DynamoDB - This is the correct option. A VPC endpoint for DynamoDB allows communication between resources in your VPC and Amazon DynamoDB without traversing the internet or a NAT instance, which is more secure.
Comment: A The most secure way to access an Amazon DynamoDB table from Amazon EC2 instances in private subnets while ensuring that the traffic does not leave the AWS network is to use Amazon VPC Endpoints for DynamoDB. Amazon VPC Endpoints enable private communication between Amazon EC2 instances in a VPC and Amazon services such as DynamoDB, without the need for an internet gateway, NAT device, or VPN connection. When you create a VPC endpoint for DynamoDB, traffic from the EC2 instances to the DynamoDB table remains within the AWS network and does not traverse the public internet.
Comment: private...backend Answer A
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpointsdynamodb. html A VPC endpoint for DynamoDB enables Amazon EC2 instances in your VPC to use their private IP addresses to access DynamoDB with no exposure to the public internet. Your EC2 instances do not require public IP addresses, and you don't need an internet gateway, a NAT device, or a virtual private gateway in your VPC. You use endpoint policies to control access to DynamoDB. Traffic between your VPC and the AWS service does not leave the Amazon network.
Comment: ExamTopics.com should be sued for this answer tagged as Correct answer.
Comment: A is correct. VPC end point. D exposed to the internet
Comment: The most secure way to access the DynamoDB table while ensuring that the traffic does not leave the AWS network is Option A (Use a VPC endpoint for DynamoDB.) A VPC endpoint for DynamoDB allows you to privately connect your VPC to the DynamoDB service without requiring an Internet Gateway, VPN connection, or AWS Direct Connect connection. This ensures that the traffic between the application and the DynamoDB table stays within the AWS network and is not exposed to the public Internet.
Comment: Option B, using a NAT gateway in a public subnet, would allow the traffic to leave the AWS network and traverse the public Internet, which is less secure. Option C, using a NAT instance in a private subnet, would also allow the traffic to leave the AWS network but would require you to manage the NAT instance yourself. Option D, using the internet gateway attached to the VPC, would also expose the traffic to the public Internet.
Comment: DAX stands for DynamoDB Accelerator, and it's like a turbo boost for your DynamoDB tables. It's a fully managed, in-memory cache that speeds up the read and write performance of your DynamoDB tables, so you can get your data faster than ever before.
Comment: A. Using Amazon ElastiCache for Redis would require modifying the application code and is not specifically designed to enhance DynamoDB performance. C. Replicating data with DynamoDB global tables would require additional configuration and operational overhead. D. Using Amazon ElastiCache for Memcached with Auto Discovery enabled would also require application code modifications and is not specifically designed for improving DynamoDB performance. In contrast, option B, using Amazon DynamoDB Accelerator (DAX), is the recommended solution as it is purpose-built for enhancing DynamoDB performance without the need for application reconfiguration. DAX provides a managed caching layer that significantly reduces read latency and offloads traffic from DynamoDB tables.
Comment: Use the turbo
Comment: B: https://aws.amazon.com/dynamodb/dax/ improve 10x performance (marketing pitch on above link) with fully managed service so no reconfiguration or operational overhead involved.
Comment: Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available caching service built for Amazon DynamoDB. DAX delivers up to a 10 times performance improvement—from milliseconds to microseconds—even at millions of requests per second. https://aws.amazon.com/dynamodb/dax/#:~:text=Amazon%20DynamoDB%20Accelerator%20(-,DAX),-is%20a%20fully
Comment: improve the performance efficiency of DynamoDB
Comment: Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that helps improve the read performance of DynamoDB tables. DAX provides a caching layer between the application and DynamoDB, reducing the number of read requests made directly to DynamoDB. This can significantly reduce read latencies and improve overall application performance.
Comment: B-->Applications that are read-intensive===>https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html#DAX.use-cases
Comment: DynamoDB Accelerator, less over head.
Comment: Option B is incorrect as the constraint in the question is not to recode the application. DAX requires application to be reconfigured and point to DAX instead of DynamoDB https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.client.modify-your-app.html Answer should be A
Comment: DAX does not require application logic modification (compatible with existing DynamoDB APIs). ElastiCache would work after changes on app's code.
Comment: To improve the performance efficiency of DynamoDB without reconfiguring the application, a solutions architect should recommend using Amazon DynamoDB Accelerator (DAX) which is Option B as the correct answer. DAX is a fully managed, in-memory cache that can be used to improve the performance of read-intensive workloads on DynamoDB. DAX stores frequently accessed data in memory, allowing the application to retrieve data from the cache rather than making a request to DynamoDB. This can significantly reduce the number of read requests made to DynamoDB, improving the performance and reducing the latency of the application.
Comment: Option A, using Amazon ElastiCache for Redis, would not be a good fit because it is not specifically designed for use with DynamoDB and would require reconfiguring the application to use it. Option C, replicating data using DynamoDB global tables, would not directly improve the performance of reading requests and would require additional operational overhead to maintain the replication. Option D, using Amazon ElastiCache for Memcached with Auto Discovery enabled, would also not be a good fit because it is not specifically designed for use with DynamoDB and would require reconfiguring the application to use it.
Comment: Option B
Comment: Agreed
Comment: B DAX is a fully managed, highly available, in-memory cache for DynamoDB that delivers lightning-fast performance and consistent low-latency responses. It provides fast performance without requiring any application reconfiguration
Comment: B is correct
Comment: DAX is the cache for this
Comment: B is correct, DAX provides caching + no changes
Comment: Using AWS Backup to copy EC2 and RDS backups to the separate Region is the solution that meets the requirements with the least operational overhead. AWS Backup simplifies the backup process and automates the copying of backups to another Region, reducing the manual effort and operational complexity involved in managing separate backup processes for EC2 instances and RDS databases. Option B is incorrect because Amazon Data Lifecycle Manager (Amazon DLM) is not designed for directly copying RDS backups to a separate region. Option C is incorrect because creating Amazon Machine Images (AMIs) and read replicas adds complexity and operational overhead compared to a dedicated backup solution. Option D is incorrect because using Amazon EBS snapshots, RDS snapshots, and S3 Cross-Region Replication (CRR) involves multiple manual steps and additional configuration, increasing complexity.
Comment: A for sure
Comment: The easiest way to backup an EC2 instance and RDS Database would be to use AWS Backup. With AWS Backup you can: Create a backup plan and select both the EC2 volume and RDS database for backup. Choose a backup schedule that meets your requirements, such as daily or weekly backups. AWS Backup will automatically take snapshots of the EC2 volume and backups of the RDS database as per the configured schedule. The backups will be stored in S3 for long term retention based on your backup plan configuration.
Comment: You can easily restore the EC2 volume or RDS database from these backups in case of data loss or corruption. AWS manages the entire backup process so there is no operational overhead for you. Some other options include using cron jobs to trigger snapshots and backups. But AWS Backup provides a fully managed service to centrally backup both EC2 and RDS with minimal effort. The above is the output from Amazon Q.
Comment: AWS Backup provides a fully managed, centralized backup service across AWS services. It can be configured to automatically copy backups across Regions. This requires minimal operational overhead compared to the other options:
Comment: D would have been a great option but the questions requires less mannual effort. So, A is better.
Comment: A is correct
Comment: Option B, using Amazon Data Lifecycle Manager (Amazon DLM) to copy EC2 backups and RDS backups to the separate Region, would require more operational overhead because DLM is primarily designed for managing the lifecycle of Amazon EBS snapshots, and would require additional configuration to manage RDS backups. Option C, creating AMIs of the EC2 instances and read replicas of the RDS DB instance in the separate Region, would require more manual effort to manage the backup and disaster recovery process, as it requires manual creation and management of AMIs and read replicas.
Comment: Option D, creating EBS snapshots and RDS snapshots, exporting them to Amazon S3, and configuring S3 Cross-Region Replication (CRR) to the separate Region, would require more configuration and management effort. Additionally, S3 CRR can have additional charges for data transfer and storage in the destination region. Therefore, option A is the best choice for meeting the company's requirements with the least operational overhead.
Comment: Option A, using AWS Backup to copy EC2 backups and RDS backups to the separate region, is the correct answer for the given scenario. Using AWS Backup is a simple and efficient way to backup EC2 instances and RDS databases to a separate region. It requires minimal operational overhead and can be easily managed through the AWS Backup console or API. AWS Backup can also provide automated scheduling and retention management for backups, which can help ensure that backups are always available and up to date.
Comment: Cross-Region backup Using AWS Backup, you can copy backups to multiple different AWS Regions on demand or automatically as part of a scheduled backup plan. Cross-Region backup is particularly valuable if you have business continuity or compliance requirements to store backups a minimum distance away from your production data. https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
Comment: A is correct - you need to find a backup solution for EC2 and RDS. DLM doent work with RDS , only with snapshots.
Comment: using Amazon DLM to copy EC2 backups and RDS backups to the separate region, is not a valid solution because Amazon DLM does not support backing up data across regions.
Comment: Option B. Use Amazon Data Lifecycle Manager (Amazon DLM) to copy EC2 backups and RDS backups to the separate Region. Amazon DLM is a fully managed service that helps automate the creation and retention of Amazon EBS snapshots and RDS DB snapshots. It can be used to create and manage backup policies that specify when and how often snapshots should be created, as well as how long they should be retained. With Amazon DLM, you can easily and automatically create and manage backups of your EC2 instances and RDS DB instances in a separate Region, with minimal operational overhead.
Comment: Buruguduystunstugudunstuy, sorry, but I haven't found any info about copying RDS backups by DLM. The DLM works only with EBS. So the only answer is A - AWS Backup
Comment: Option A, using AWS Backup to copy EC2 backups and RDS backups to the separate Region, would also work, but it may require more manual configuration and management. Option C, creating AMIs of the EC2 instances and copying them to the separate Region, and creating a read replica for the RDS DB instance in the separate Region, would work, but it may require more manual effort to set up and maintain. Option D, creating EBS snapshots and copying them to the separate Region, creating RDS snapshots, and exporting them to Amazon S3, and configuring S3 CRR to the separate Region, would also work, but it would involve multiple steps and may require more manual effort to set up and maintain. Overall, using Amazon DLM is likely to be the easiest and most efficient option for meeting the requirements with the least operational overhead.
Comment: Some of your answers are very detailed. Can you back them up with a reference?
Comment: All of their answers are from ChatGPT
Comment: using Amazon DLM to copy EC2 backups and RDS backups to the separate region, is not a valid solution because Amazon DLM does not support backing up data across regions.
Comment: Thanks techhb
Comment: I choose A, but DLM support cross regions. DLM doesn't support RDS. Cross region copy rules it's a feature of DLM ("For each schedule, you can define the frequency, fast snapshot restore settings (snapshot lifecycle policies only), cross-Region copy rules, and tags") https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html
Comment: This guy is giving wrong answers in detail...lol
Comment: AWS DLM does not support RDS backups, only works with EBS storage. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html
Comment: Option A as it is fully managed service with least operational overhead
Comment: A AWS Backup is a fully managed service that handles the process of copying backups to a separate Region automatically
Comment: Ans A with least operational overhead
Comment: AWS Backup supports Supports cross-region backups
Comment: Option A Aws back up supports , EC2, RDS
Comment: AWS Backup suports Supports cross-region backups
Comment: CORRECT Option A To securely store a database user name and password in AWS Systems Manager Parameter Store and allow an application running on an EC2 instance to access it, the solutions architect should create an IAM role that has read access to the Parameter Store parameter and allow Decrypt access to an AWS KMS key that is used to encrypt the parameter. The solutions architect should then assign this IAM role to the EC2 instance. This approach allows the EC2 instance to access the parameter in the Parameter Store and decrypt it using the specified KMS key while enforcing the necessary security controls to ensure that the parameter is only accessible to authorized parties.
Comment: Option B, would not be sufficient, as IAM policies cannot be directly attached to EC2 instances. Option C, would not be a valid solution, as the Parameter Store parameter and the EC2 instance are not entities that can be related through an IAM trust relationship. Option D, would not be a valid solution, as the trust policy would not allow the EC2 instance to access the parameter in the Parameter Store or decrypt it using the specified KMS key.
Comment: Agree with A, IAM role is for services (EC2 for example) IAM policy is more for users and groups
Comment: A all day. Don't even need to read the other answers. You can't attach a policy to EC2. You have to attach a role.
Comment: policy needs to be assigned to something so B is inaccurate CD are just made up things
Comment: Create an IAM role that has read access to the Parameter Store parameter. Allow Decrypt access to an AWS Key Management Service (AWS KMS) key that is used to encrypt the parameter. Assign this IAM role to the EC2 instance
Comment: CORRECT Option A
Comment: By creating an IAM role with read access to the Parameter Store parameter and Decrypt access to the associated AWS KMS key, the EC2 will have the necessary permissions to securely retrieve and decrypt the database user name and password from the Parameter Store. This approach ensures that the sensitive information is protected and can be accessed only by authorized entities. Answers B, C, and D are not correct because they do not provide a secure way to store and retrieve the database user name and password from the Parameter Store. IAM policies, trust relationships, and associations with the DB instance are not the appropriate mechanisms for securely managing sensitive credentials in this scenario. Answer A is the correct choice as it involves creating an IAM role with the necessary permissions and assigning it to the EC2 instance to access the Parameter Store securely.
Comment: A is correct
Comment: By creating an IAM role and assigning it to the EC2 instance, the application running on the EC2 instance can access the Parameter Store parameter securely without the need for hard-coding the database user name and password in the application code. The IAM role should have read access to the Parameter Store parameter and Decrypt access to an AWS KMS key that is used to encrypt the parameter to ensure that the parameter is protected at rest.
Comment: There should be the Decrypt access to KMS. "If you choose the SecureString parameter type when you create your parameter, Systems Manager uses AWS KMS to encrypt the parameter value." https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html IAM role - for EC2
Comment: A -- is correct option
Comment: Option A.
Comment: A is correct
Comment: Answer A Create an IAM role that has read access to the Parameter Store parameter. Allow Decrypt access to an AWS Key Management Service (AWS KMS) key that is used to encrypt the parameter. Assign this IAM role to the EC2 instance. This solution will allow the application to securely access the database user name and password stored in the parameter store.
Comment: i think policy
Comment: can you attach policy to ec2 directly ?
Comment: https://aws.amazon.com/blogs/compute/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/
Comment: This link gives the example "Walkthrough: Securely access Parameter Store resources with IAM roles for tasks" - essentially A above. It doe snot show how this can be done using a policy (B) alone.
Comment: Access to Parameter Store is enabled by IAM policies and supports resource level permissions for access. An IAM policy that grants permissions to specific parameters or a namespace can be used to limit access to these parameters. CloudTrail logs, if enabled for the service, record any attempt to access a parameter.
Comment: IAM Policies can be attached to IAM roles, and EC2 instances can be allowed to use IAM roles. You can't attach an IAM policy to an EC2 instance.
Comment: A. Attach IAM role to EC2 Instance https://aws.amazon.com/blogs/security/digital-signing-asymmetric-keys-aws-kms/
Comment: Attach IAM role to EC2 Instance profile
Comment: Shield - Load Balancer, CF, Route53 AWF - CF, ALB, API Gateway
Comment: Thank u U meant WAF* - CloudFormation, right? haha
Comment: Shield - Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53. WAF - Amazon CloudFront, the Application Load Balancer (ALB), Amazon API Gateway, and AWS AppSync
Comment: AWS Shield Advanced - DDos attacks AWS WAF to protect Amazon API Gateway, because WAF sits before the API Gateway and then comes NLB.
Comment: don't agree that NLB sits before API gateway. it should be other way around
Comment: yes.. coming from outside to inside... first of all DDos protection is required so the outer most NLB with Shield Advanced and then filter particular request doing SQL injection and all i.e API Gateway with WAF
Comment: B- (Shield Advance) PROTECT the platform against web exploits like SQL injection D- (GuardDuty) also wants to DETECT mitigate large, sophisticated DDoS attacks WAF use for filter traffic, not make sense here.
Comment: Shield advanced does not protect against SQL injection. That is what WAF is for. GuardDuty is not the right tool here. Answers are B and C bro.
Comment: B) Use AWS Shield Advanced with the NLB C) Use AWS WAF to protect Amazon API Gateway The key reasons are: AWS Shield Advanced provides expanded DDoS protection against larger and more sophisticated attacks Using it with the NLB helps protect against network floods WAF still provides critical protection against exploits at the API lay
Comment: WAF - can't support NLB and its supports API Gateway AWS Shield Advanced - NLB - DDOS
Comment: B. AWS Shield Advanced provides advanced DDoS protection for the NLB, making it the appropriate choice for protecting against large and sophisticated DDoS attacks at the network layer. C. AWS WAF is designed to provide protection at the application layer, making it suitable for securing the API Gateway against web exploits like SQL injection. A. AWS WAF is not compatible with NLB as it operates at the application layer, whereas NLB operates at the transport layer. D. While GuardDuty helps detect threats, it does not directly protect against web exploits or DDoS attacks. Shield Standard focuses on edge resources, not specifically NLBs. E. Shield Standard provides basic DDoS protection for edge resources, but it does not directly protect the NLB or address web exploits at the application layer.
Comment: B and C is correct
Comment: NLB is a Lyer 3/4 component while WAF is a Layer 7 protection component. That is why WAF is only available for Application Load Balancer in the ELB portfolio. NLB does not terminate the TLS session therefore WAF is not capable of acting on the content. I would consider using AWS Shield at Layer 3/4. https://repost.aws/questions/QU2fYXwSWUS0q9vZiWDoaEzA/nlb-need-to-attach-aws-waf
Comment: • A. Use AWS WAF to protect the NLB. INCORRECT, cos' WAF not integrate with network LB • B. Use AWS Shield Advanced with the NLB. YES. AWS Shield Advanced provides additional protections against more sophisticated and larger attacks for your applications running in AWS. The doubt is : why apply the protection in the NLB when the facing of the app. is the API Gateway?, because Shield shoud be in front of the communications, not behind. Nevertheless, this is the best option. • C. Use AWS WAF to protect Amazon API Gateway. YES, https://aws.amazon.com/es/waf/faqs/ • D. Use Amazon GuardDuty with AWS Shield Standard INCORRECT, GuardDuty not prevent attacks. •E. Use AWS Shield Standard with Amazon API Gateway. INCORRECT. It could be, in principle, a good option, cos' it's in front of the gateway, but the questions said explicity: "wants to detect and mitigate large, sophisticated DDoS attacks", and Standard not provide this feature.
Comment: for those who select A, it is wrong, WAF is Layer 7, it only support ABL, APIGateway, CloudFront,COgnito User Pool and AppSync graphQL API (https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html). NLB is NOT supported. Answer is BC
Comment: A and B are the best options to provide the greatest protection for the platform against web vulnerabilities and large, sophisticated DDoS attacks. Option A: Use AWS WAF to protect the NLB. This will provide protection against common web vulnerabilities such as SQL injection. Option B: Use AWS Shield Advanced with the NLB. This will provide additional protection against large and sophisticated DDoS attacks.
Comment: The best protection for the platform would be to use A and C together because it will protect both the NLB and the API Gateway from web vulnerabilities and DDoS attacks.
Comment: correct
Comment: A and C are the best options for protecting the platform against web vulnerabilities and detecting and mitigating large and sophisticated DDoS attacks. A: AWS WAF can be used to protect the NLB from web vulnerabilities such as SQL injection. C: AWS WAF can be used to protect Amazon API Gateway and also provide protection against DDoS attacks. B: AWS Shield Advanced is used to protect resources from DDoS attacks, but it is not specific to the NLB and may not provide the same level of protection as using WAF specifically on the NLB. D and E: Amazon GuardDuty and AWS Shield Standard are primarily used for threat detection and may not provide the same level of protection as using WAF and Shield Advanced.
Comment: A is not correct as WAF doesn't support Network Load Balancer
Comment: WS Shield Advanced can help protect your Amazon EC2 instances and Network Load Balancers against infrastructure-layer Distributed Denial of Service (DDoS) attacks. Enable AWS Shield Advanced on an AWS Elastic IP address and attach the address to an internet-facing EC2 instance or Network Load Balancer.https://aws.amazon.com/blogs/security/tag/network-load-balancers/
Comment: Regional resources You can protect regional resources in all Regions where AWS WAF is available. You can see the list at AWS WAF endpoints and quotas in the Amazon Web Services General Reference. You can use AWS WAF to protect the following regional resource types: Amazon API Gateway REST API Application Load Balancer AWS AppSync GraphQL API Amazon Cognito user pool You can only associate a web ACL to an Application Load Balancer that's within AWS Regions. For example, you cannot associate a web ACL to an Application Load Balancer that's on AWS Outposts.
Comment: Ans:-a and C
Comment: ***CORRECT*** A. Use AWS WAF to protect the NLB. C. Use AWS WAF to protect Amazon API Gateway. AWS WAF is a web application firewall that helps protect web applications from common web exploits such as SQL injection and cross-site scripting attacks. By using AWS WAF to protect the NLB and Amazon API Gateway, the company can provide an additional layer of protection for its cloud communications platform against these types of web exploits.
Comment: Your answer is wrong. Sophisticated DDOS = Shield Advanced (DD0S attacks the front!) What happens if your load balances goes down? Your API gateway is on the BACK further behind the NLB. SQL Protect that with the WAF B and C are right.
Comment: This guy just copies and pastes from ChatGPT.
Comment: About AWS Shield Advanced and Amazon GuardDuty AWS Shield Advanced is a managed DDoS protection service that provides additional protection for Amazon EC2 instances, Amazon RDS DB instances, Amazon Elastic Load Balancers, and Amazon CloudFront distributions. It can help detect and mitigate large, sophisticated DDoS attacks, "but it does not provide protection against web exploits like SQL injection." Amazon GuardDuty is a threat detection service that uses machine learning and other techniques to identify potentially malicious activity in your AWS accounts. It can be used in conjunction with AWS Shield Standard, which provides basic DDoS protection for Amazon EC2 instances, Amazon RDS DB instances, and Amazon Elastic Load Balancers. However, neither Amazon GuardDuty nor AWS Shield Standard provides protection against web exploits like SQL injection. Overall, the combination of using AWS WAF to protect the NLB and Amazon API Gateway provides the most protection against web exploits and large, sophisticated DDoS attacks.
Comment: Option B and C
Comment: B and C
Comment: B & C is the answer
Comment: Option B, using Amazon Simple Notification Service (SNS), would not be suitable for this use case, as SNS is a pub/sub messaging service that is designed for one-to-many communication, rather than point-to-point communication between specific microservices. Option C, using an AWS Lambda function to pass messages, would not be suitable for this use case, as it would require the data producers and data consumers to have a direct connection and invoke the Lambda function, rather than being decoupled through a message queue. Option D, using an Amazon DynamoDB table with DynamoDB Streams, would not be suitable for this use case, as it would require the data consumers to continuously poll the DynamoDB Streams API to detect new table entries, rather than being notified of new data through a message queue.
Comment: Hence, Option A is the correct answer. Create an Amazon Simple Queue Service (Amazon SQS) queue. Add code to the data producers, and send data to the queue. Add code to the data consumers to process data from the queue.
Comment: A. Creating an Amazon SQS queue allows for asynchronous communication between microservices, decoupling the data producers and consumers. It provides scalability, flexibility, and ensures that data processing can happen independently and at a desired pace. B. Amazon SNS is more suitable for pub/sub messaging, where multiple subscribers receive the same message. It may not be the best fit for sequential data processing. C. Using AWS Lambda functions for communication introduces unnecessary complexity and may not be the optimal solution for sequential data processing. D. Amazon DynamoDB with DynamoDB Streams is primarily designed for real-time data streaming and change capture scenarios. It may not be the most efficient choice for sequential data processing in a microservices architecture.
Comment: A for sure
Comment: To Decouple a monolithic application - SQS - SQS standard - not in order - SQS FIFO - in order
Comment: Data is processed sequentially, but the order of results does not matter => SQS; if order matters => SQL FIFO
Comment: A is the answer.
Comment: Data is processed sequentially, but the order of results does not matter = Amazon Simple Queue Service
Comment: A) Create an Amazon Simple Queue Service (Amazon SQS) queue. Add code to the data producers, and send data to the queue. Add code to the data consumers to process data from the queue. For asynchronous communication between decoupled microservices, an SQS queue is the most appropriate service to use. SQS provides a scalable, highly available queue to buffer messages between producers and consumers. The order of processing does not matter, so a queue model fits well. The consumers can scale independently to process messages from the queue.
Comment: BBBBBBBBB
Comment: SQS for decoupling a monolithic architecture, hence option A is the right answer.
Comment: it also says 'the order of results does not matter'. Option B is correct.
Comment: The answer is A. B is wrong because SNS cannot send events "directly" to ECS. https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html
Comment: it deosn;t say it is one-one relationships , SNS is better
Comment: watch out for this sentence in the question..."Data needs to process sequentially...."
Comment: Best answer is A. Though C or D is possible it requires additional components and integration and so they are not efficient. Assuming that rate of incoming requests is within limits that SQS can handle A is best option.
Comment: A is correct
Comment: answer is B. An Amazon Simple Notification Service (Amazon SNS) topic can be used for communication between the microservices in this scenario. The data producers can be configured to publish notifications to the topic, and the data consumers can be configured to subscribe to the topic and receive notifications as they are published. This allows for asynchronous communication between the microservices, Question here focus on communication between microservices
Comment: We need decoupling so ok to use SQS
Comment: Amazon RDS MySQL DB instance with Multi-AZ functionality enabled to synchronously replicate the data Standby DB in Multi-AZ- synchronous replication Read Replica always asynchronous. so option C is ignored.
Comment: RDS Multi-AZ = Synchronous = Disaster Recovery (DR) Read Replica = Asynchronous = High Availability
Comment: B is correct but the explanation is flawed ;) RDS Multi-AZ = Synchronous = High Availability Read Replica = Asynchronous = Disaster Recovery (DR)
Comment: "Minimizes Data Loss" Therefore answer is B. Amazon RDS read replicas use asynchronous replication, not synchronous. Therefore, this option does not meet the requirement for minimizing data loss as asynchronous replication can result in data lag.
Comment: Answer is B Find the below URL for the perfect explanation for the differences between: - Multi-AZ DB - Multi-Region DB - Read replicas DB https://aws.amazon.com/rds/features/read-replicas/
Comment: Multi AZ for availability
Comment: Option A is incorrect because Amazon RDS does not support synchronous replication to three nodes in three Availability Zones. Option C is incorrect because while you can create a read replica in a separate AWS Region1, the replication from the primary DB instance to the read replica is asynchronous, not synchronous.
Comment: B. Create an Amazon RDS MySQL DB instance with Multi-AZ functionality enabled to synchronously replicate the data. Enabling Multi-AZ functionality in Amazon RDS ensures synchronous replication of data to a standby replica in a different Availability Zone. This provides high availability and minimizes data loss in the event of a database outage. A. Creating an Amazon RDS DB instance with synchronous replication to three nodes in three Availability Zones would provide even higher availability but is not necessary for the stated requirements. C. Creating a read replica in a separate AWS Region would provide disaster recovery capabilities but does not ensure synchronous replication or meet the requirement of storing every transaction on at least two nodes. D. Using an EC2 instance with a MySQL engine and triggering an AWS Lambda function for replication introduces unnecessary complexity and is not the most suitable solution for ensuring reliable and synchronous replication.
Comment: B since all other answers r wrong
Comment: B Since read replica is async.
Comment: Multi AZ is not as protected as Multi-Region Read Replica.
Comment: But is IS protected. Read replica is asynchronous, fails to meet the "store EVERY transaction on at least two nodes" requirement.
Comment: I curios to know why A isn't right. Is it just that it would take more effort?
Comment: How would you implement A?
Comment: B is correct C requires more wokr.
Comment: Option B
Comment: Multi-AZ will give at least two nodes as required by the question. The answer is B. Amazon RDS provides high availability and failover support for DB instances using Multi-AZ deployments with a single standby DB instance. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html
Comment: Option B
Comment: Option A is the correct answer in this scenario because it meets the requirements specified in the question. It creates an Amazon RDS DB instance with synchronous replication to three nodes in three Availability Zones, which will provide high availability and durability for the database, ensuring that the data is stored on multiple nodes and automatically replicated across Availability Zones. Option B is not a correct answer because it creates an Amazon RDS MySQL DB instance with Multi-AZ functionality enabled, which only provides failover capabilities. It does not enable synchronous replication to multiple nodes, which is required in this scenario.
Comment: Option B is not incorrect: "The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy and minimize latency spikes during system backups" from https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html
Comment: I would go with Option B since it meets the company's requirements and is the most suitable solution. By creating an Amazon RDS MySQL DB instance with Multi-AZ functionality enabled, the solutions architect will ensure that data is automatically synchronously replicated across multiple AZs within the same Region. This provides high availability and data durability, minimizing the risk of data loss and ensuring that every transaction is stored on at least two nodes.
Comment: Maybe C since Amazon RDC now supports cross region read replica https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-rds-sql-server-cross-region-read-replica/
Comment: A - is correct, because Dynamodb on-demand scales write and read capacity B - Aurora auto scaling scales only read replicas
Comment: That's not correct. Amazon Aurora with Aurora Auto Scaling can scale both read and write replicas. Is there anything else you would like me to help you with?
Comment: Could you point us to a source where it says that Aurora Auto Scaling can scale write replicas? The AWS documentation specifically mentions that it supports only read replicas (e.g. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html): To meet your connectivity and workload requirements, Aurora Auto Scaling dynamically adjusts the number of Aurora Replicas (reader DB instances) provisioned for an Aurora DB cluster. Aurora Auto Scaling is available for both Aurora MySQL and Aurora PostgreSQL.
Comment: That's why Dynamo DB is best suited option
Comment: Correct...Both can serve purpose but note the keyword "must scale read and write capacity as quickly as possible to meet changes in user demand". DynamoDB can scale quickly than Aurora. Remember "PUSH BUTTON SCALING FEATURE" of Dynamo DB.
Comment: please is this dump enough to pass the exam?
Comment: I HOPE SO
Comment: You can tell us now ? Going by the date of your post I guess you would have challenged the exam by now ? so how did it go ?
Comment: did you pass ?
Comment: Dynamo DB Push Scaling
Comment: https://aws.amazon.com/blogs/database/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/#:~:text=Are%20working%20with%20an%20online%20transaction%20processing%20(OLTP)%20workload.%20High%2Dperformance%20reads%20and%20writes%20are%20easy%20to%20manage%20with%20DynamoDB%2C%20and%20you%20can%20expect%20performance%20that%20is%20effectively%20constant%20across%20widely%20varying%20loads.
Comment: C,D are out due to EC2 scaling which is not ideal for static content scaling. A and B are logical choices. B uses Aurora which is more for relational database and comes with the baggage and limitations of RDBMS scaling. DynamDB (no SQL) is easier to scale for both read and write. A is simply better than be for an ordering website so that is the better option. Note that B would have been good if A wasn't a choice.
Comment: Where do you see "static content scaling"? In the question, I can read "dynamic ordering website", I fail to see how dynamic website can be hosted on S#.
Comment: dynamodb is serverless
Comment: Hi all! The answer is A and NOT B on this one as the company is building an ordering website (OLTP). DynamoDB's high performance read and writes are perfect for an OLTP use case. https://aws.amazon.com/blogs/database/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/
Comment: S3 is discarded since the question says: A company is building a new dynamic ordering website,
Comment: minimize server maintenance and patching, highly available, scale read and write = serverless = Amazon S3, Amazon API Gateway, AWS Lambda, Amazon DynamoDB
Comment: Key phrase in the Question is must scale read and write capacity. Aurora is only for Read. Amazon DynamoDB has two read/write capacity modes for processing reads and writes on your tables: On-demand Provisioned (default, free-tier eligible) https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
Comment: Minimize maintenance & Patching = Serverless S3, DynamoDB are serverless
Comment: Minimize maintenance & Patching = Serverless services Serverless services with no sql database is perfect combination
Comment: B. This solution leverages serverless technologies like API Gateway and Lambda for hosting dynamic content, reducing server maintenance and patching. Aurora with Aurora Auto Scaling provides a highly available and scalable database solution. Hosting static content in S3 and configuring CloudFront for content delivery ensures high availability and efficient scaling. A. Using DynamoDB with on-demand capacity may provide scalability, but it does not offer the same level of flexibility and performance as Aurora. Additionally, it does not address the hosting of dynamic content using serverless technologies. C. Hosting all the website content on EC2 instances requires server maintenance and patching. While using ASG and an ALB helps with availability and scalability, it does not minimize server maintenance as requested. D. Hosting all the website content on EC2 instances introduces server maintenance and patching. Using Aurora with Aurora Auto Scaling is a good choice for the database, but it does not address the need to minimize server maintenance and patching for the overall infrastructure.
Comment: B isn't correct because of cooldown You can tune the responsiveness of a target-tracking scaling policy by adding cooldown periods that affect scaling your Aurora DB cluster in and out. A cooldown period blocks subsequent scale-in or scale-out requests until the period expires. These blocks slow the deletions of Aurora Replicas in your Aurora DB cluster for scale-in requests, and the creation of Aurora Replicas for scale-out requests.
Comment: Key word in question "storing ordering data" DynamoDB is perfect for storing ordering data (key-values)
Comment: Minimize maintenance & Patching = Serverless S3, DynamoDB are serverless
Comment: The company wants to minimize server maintenance and patching -> Serverless (minimize) C,D are wrong because these are not serverless B is wrong because RDS is not serverless -> A full serverless
Comment: For anyone who is confused about Option B, there's a serverless Aurora service called "Aurora Serverless v2". This will bring us an equivalent solution to option A. But the Option B in the question only states the Aurora, therefore by default we need to manage the servers underneath. Ref: https://www.projectpro.io/article/aws-aurora-vs-rds/737#:~:text=RDS%20is%20a%20fully%2Dmanaged,manual%20management%20of%20database%20servers.
Comment: To configure a VPC for an existing function: 1. Open the Functions page of the Lambda console. 2. Choose a function. 3. Choose Configuration and then choose VPC. 4. Under VPC, choose Edit. 5. Choose a VPC, subnets, and security groups. <-- **That's why I believe the answer is A**. Note: If your function needs internet access, use network address translation (NAT). Connecting a function to a public subnet doesn't give it internet access or a public IP address.
Comment: The question says on-prem database...how do we create a SG for that instance in AWS? C make sense. my 2 cents..
Comment: SG is for Lambda and not for the on-prem database. A is the correct option
Comment: A is correct. To configure SG for Lambda , go to Lambda function -> Configure -> Edit VPC and scroll down to see "security groups" where you can configure Lambda for VPC. Also see here https://repost.aws/questions/QUSaj1a6jBQ92Kp56klbZFNw/aws-lambda-to-on-premise-via-direct-connect-and-aws-privatelink
Comment: it is A. C is not correct at all as in the question it metions that the VPC already has connectivity with on-premises
Comment: C says to "update the route table" not create a new connection. C is correct.
Comment: C is wrong. Lambda can't connect by default to resources in a private VPC, so you have to do some specific setup steps to run in a private VPC, Answer A is correct
Comment: No need to do route updates. This is because the route to the destination on-premises is already set.
Comment: either A or C
Comment: C is correect as lambda already in VPC and AWS account already has connection setup with on-premise database in private subnet
Comment: B,C,D dont have any logic behind them. A is the most logical answer as you need to connect a function to a VPC. The VPC will be connected to the on-prem database.
Comment: Answer A: During Lambda function creation select "Advanced Settings" select "Enable VPC", this will allow you to select VPC, Subnets and SecurityGroup for your Lambda function. This is the way Lambda can get controlled access to resouces in your VPC. Default Lambda Settings: When you create a Lambda function without specifying a VPC, the Lambda function does not get associated with any particular VPC. By default, Lambda functions are not deployed within a VPC and do not have access to resources within a VPC, such as EC2 instances, RDS databases, or Elasticache clusters, unless you explicitly configure the Lambda function to connect to a VPC.
Comment: Update the route tables in the VPC to allow the Lambda function to access the on-premises data center through Direct Connect. By updating the route tables in the VPC to allow the Lambda function to access the on-premises data center through Direct Connect, is the most appropriate solution. By updating the route tables, you can specify the route for traffic from the Lambda function to the IP address range of the on-premises data center via the Direct Connect connection. This ensures that the Lambda function can securely communicate with the database in the private subnet of the data center.
Comment: Every time I read this question the badly phrased options make no sense at all. I now want to vote for A but it makes no sense. Question says: All non-VPC traffic routes to the virtual private gateway So Lambda is technically a non VPC traffic too. This means it already goes through the VPGW but we don't know what it connects. Assuming it connect the data-centre to AWS then A makes sense. BUT all this is based on different interpretation now for me.
Comment: The wording is strange because technically, the Lambda function does not "run in the VPC", rather it is connected to the VPC, but otherwise A is what relevant documentation says - connect the Lambda function to the VPN and allow traffic in the security group. Not B, we have Direct Connect, no need for VPN. Not C, route is already in place. And route alone does not help - the "route tables in the VPC" are completely irrelevant as long as we don't connect the Lambda function to the VPC. Not D, an "Elastic IP address" is always connected to an "elastic network interface", such is created automatically with A.
Comment: I agree with explanation!
Comment: The question and options are very badly worded so it makes C a possible candidate (unconvincingly though!). B: VPN is not needed as Direct Connect is already there D: Irrelevant A is too generic (appropriate security group for what?) Lambda has fixed VPC or ENI C is logically relevant
Comment: A says "configure the Lambda function to RUN IN the VPC", but "a Lambda function ALWAYS runs inside a VPC owned by the Lambda service" (https://docs.aws.amazon.com/lambda/latest/dg/foundation-networking.html). "You can configure a Lambda function to CONNECT TO private subnets in a virtual private cloud (VPC) in your AWS account", but "connect to" is not the same as "run in" (https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html). Otherwise A would make sense (you CAN assign a security group to the Elastic Network Interface that Lambda uses to connect to your VPC).
Comment: B We already have Direct Connect, so why set up VPN C doesn't make sense because "all non-VPC traffic [already] routes to the virtual private gateway" (which is obviously connected to the Direct Connect gateway), so why should you "update the route tables"? D sounds plausible; however, an Elastic IP address is associated with an Elastic Network Interface (though that is automatically provided by AWS). So the "without an elastic network interface" makes D wrong. My best guess is that there's a typo or misunderstanding in the answers. It's either A but it should read "connect to the VPC" instead of "run in the VPC", or it's D but it should read "without CREATING an elastic network interface" or "WITH an elastic network interface".
Comment: it's not A: A Lambda function always runs inside a VPC owned by the Lambda service. https://docs.aws.amazon.com/lambda/latest/dg/foundation-networking.html
Comment: The answer is C. The question is to allow lambda to access the database running in private subnet in the corporate data center. The only connectivity with the data center is Direct connect.
Comment: Answer C is correct: https://repost.aws/questions/QUSaj1a6jBQ92Kp56klbZFNw/aws-lambda-to-on-premise-via-direct-connect-and-aws-privatelink
Comment: Go to the Lambda console. Click the Functions tab. Select the Lambda function that you want to configure. Click the Configuration tab. In the Network section, select the VPC that you want the function to run in. In the Security groups section, select the security group that you want to allow the function to access the database subnet. Click the Save button.
Comment: Correct answer is A Lambda is available in the Region by default.. if you want to connect it to your private subnet or to on prem data center you must configure your Lambda with vpc.. C is wrong because there is no help adding routes to VPC without configuring your lambda to vpc.
Comment: Option A: Configure the Lambda function to run in the VPC with the appropriate security group. This allows the Lambda function to access the database in the private subnet of the company's data center. By running the Lambda function in the VPC, it can communicate with resources in the private subnet securely. Option B is incorrect because setting up a VPN connection and routing the traffic from the Lambda function through the VPN would add unnecessary complexity and overhead. Option C is incorrect because updating the route tables in the VPC to allow access to the on-premises data center through Direct Connect would affect the entire VPC's routing, potentially exposing other resources to the on-premises network. Option D is incorrect because creating an Elastic IP address and sending traffic through it without an elastic network interface is not a valid configuration for accessing resources in a private subnet.
Comment: To ensure that an Amazon Elastic Container Service (ECS) application has permission to access Amazon Simple Storage Service (S3), the correct solution is to create an AWS Identity and Access Management (IAM) role with the necessary S3 permissions and specify that role as the taskRoleArn in the task definition for the ECS application. Option B, creating an IAM role with S3 permissions and specifying that role as the taskRoleArn in the task definition, is the correct solution to meet the requirement.
Comment: Option A, updating the S3 role in IAM to allow read/write access from ECS and relaunching the container, is not the correct solution because the S3 role is not associated with the ECS application. Option C, creating a security group that allows access from ECS to S3 and updating the launch configuration used by the ECS cluster, is not the correct solution because security groups are used to control inbound and outbound traffic to resources, and do not grant permissions to access resources. Option D, creating an IAM user with S3 permissions and relaunching the EC2 instances for the ECS cluster while logged in as this account, is not the correct solution because it is generally considered best practice to use IAM roles rather than IAM users to grant permissions to resources.
Comment: B. Create an IAM role with S3 permissions, and then specify that role as the taskRoleArn in the task definition
Comment: Option B: Create an IAM role with S3 permissions and specify that role as the taskRoleArn in the task definition. This approach allows the ECS task to assume the specified role and gain the necessary permissions to access Amazon S3. Option A is incorrect because updating the S3 role in IAM and relaunching the container does not associate the updated role with the ECS task. Option C is incorrect because creating a security group that allows access from Amazon ECS to Amazon S3 does not grant the necessary permissions to the ECS task. Option D is incorrect because creating an IAM user with S3 permissions and relaunching the EC2 instances for the ECS cluster does not associate the IAM user with the ECS task.
Comment: https://repost.aws/knowledge-center/ecs-fargate-access-aws-services
Comment: https://www.examtopics.com/discussions/amazon/view/27954-exam-aws-certified-solutions-architect-associate-saa-c02/ https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-taskdefinition.html
Comment: The short name or full Amazon Resource Name (ARN) of the AWS Identity and Access Management role that grants containers in the task permission to call AWS APIs on your behalf.
Comment: Option B
Comment: Option B.
Comment: Agreed
Comment: B is the best answer
Comment: B is correct
Comment: The answer is B.
Comment: B is the answer
Comment: Correct is B FSx --> shared Windows file system（SMB） EFS --> Linux NFS
Comment: Windows file system = Amazon FSx for Windows File Server
Comment: Configure Amazon FSx for Windows File Server. Mount the Amazon FSx file system to each Windows instance.
Comment: Option B: Configure Amazon FSx for Windows File Server. This service provides a fully managed Windows file system that can be easily shared across multiple EC2 Windows instances. It offers high performance and supports Windows applications that require file storage. Option A is incorrect because AWS Storage Gateway in volume gateway mode is not designed for shared file systems. Option C is incorrect because while Amazon EFS can be mounted to multiple instances, it is a Linux-based file system and may not be suitable for Windows applications. Option D is incorrect because attaching and mounting an Amazon EBS volume to multiple instances simultaneously is not supported.
Comment: Option B is right answer.
Comment: References : https://www.examtopics.com/discussions/amazon/view/28006-exam-aws-certified-solutions-architect-associate-saa-c02/ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/wfsx-volumes.html
Comment: EFS is not compatible with Windows. https://pilotcoresystems.com/insights/ebs-efs-fsx-s3-how-these-storage-options-differ/#:~:text=EFS%20works%20with%20Linux%20and,with%20all%20Window%20Server%20platforms.
Comment: A. Configure AWS Storage Gateway in volume gateway mode. Mount the volume to each Windows instance. This option is incorrect because AWS Storage Gateway is not a file storage service. It is a hybrid storage service that allows you to store data in the cloud while maintaining low-latency access to frequently accessed data. It is designed to integrate with on-premises storage systems, not to provide file storage for Amazon EC2 instances. B. Configure Amazon FSx for Windows File Server. Mount the Amazon FSx file system to each Windows instance. This is the correct answer. Amazon FSx for Windows File Server is a fully managed file storage service that provides a native Windows file system that can be accessed over the SMB protocol. It is specifically designed for use with Windows-based applications, and it can be easily integrated with existing applications by mounting the file system to each EC2 instance.
Comment: C. Configure a file system by using Amazon Elastic File System (Amazon EFS). Mount the EFS file system to each Windows instance. This option is incorrect because Amazon EFS is a file storage service that is designed for use with Linux-based applications. It is not compatible with Windows-based applications, and it cannot be accessed over the SMB protocol. D. Configure an Amazon Elastic Block Store (Amazon EBS) volume with the required size. Attach each EC2 instance to the volume. Mount the file system within the volume to each Windows instance. This option is incorrect because Amazon EBS is a block storage service, not a file storage service. It is designed for storing raw block-level data that can be accessed by a single EC2 instance at a time. It is not designed for use as a shared file system that can be accessed by multiple instances.
Comment: B - is correct
Comment: Option B
Comment: B is correct
Comment: B FSx for windows
Comment: B is correct option
Comment: Amazon FSx for Windows File Server
Comment: https://containersonaws.com/introduction/ec2-or-aws-fargate/ A.(O) multi-az <= 'little intervention' B.(X) read replica <= Promoting a read replica to be a standalone DB instance You can promote a read replica into a standalone DB instance. When you promote a read replica, the DB instance is rebooted before it becomes available. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html C.(X) use Amazon ECS instead of EC2-based docker for little human intervention D.(O) Amazon ECS on AWS Fargate : AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. E.(X) EC2 launch type The EC2 launch type can be used to run your containerized applications on Amazon EC2 instances that you register to your Amazon ECS cluster and manage yourself.
Comment: Highly available application - Amazon RDS DB instance in Multi-AZ little manual intervention - Fargate
Comment: highly available application, little manual intervention = serverless = Amazon Elastic Container Service with Fargate and Amazon RDS DB instance in Multi-AZ mode
Comment: The correct answers are A and D. A) Creating an RDS DB instance in Multi-AZ mode provides automatic failover to a standby replica in another Availability Zone, providing high availability. D) Using ECS Fargate removes the need to provision and manage EC2 instances, allowing the service to scale dynamically based on demand. ECS handles load balancing and availability out of the box.
Comment: AD is the correct answer
Comment: A. Create an Amazon RDS DB instance in Multi-AZ mode. This ensures that the database is highly available with automatic failover to a standby replica in another Availability Zone. D. Create an Amazon Elastic Container Service (Amazon ECS) cluster with a Fargate launch type to handle the dynamic application load. Fargate abstracts the underlying infrastructure, automatically scaling and managing the containers, making it a highly available and low-maintenance option. Option B is not the best choice as it only creates replicas in another Availability Zone without the automatic failover capability provided by Multi-AZ mode. Option C is not the best choice as managing a Docker cluster on EC2 instances requires more manual intervention compared to using the serverless capabilities of Fargate in option D. Option E is not the best choice as it uses the EC2 launch type, which requires managing and scaling the EC2 instances manually. Fargate, as mentioned in option D, provides a more automated and scalable solution.
Comment: little manual intervention = Serverless
Comment: Option A&D
Comment: A and D
Comment: A and D
Comment: A and D
Comment: A and D are the options
Comment: AD for sure Link: https://www.examtopics.com/discussions/amazon/view/43729-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: For Exam : Whenever you see SFTP , FTP look for "Transfer" in options available
Comment: + FTPS
Comment: Answer is A AWS Transfer Family securely scales your recurring business-to-business file transfers to AWS Storage services using SFTP, FTPS, FTP, and AS2 protocols. https://aws.amazon.com/aws-transfer-family/
Comment: Answer A is not an answer because it requires more mannual efford. While AWS Transfer Family simplifies the setup of an SFTP server, it still requires management and monitoring. This includes handling scaling, backups, patching, and other administrative tasks associated with managing an SFTP server.
Comment: Option A is the most suitable choice for implementing a highly available SFTP solution with minimal operational overhead in this scenario
Comment: The key advantages of AWS Transfer Family are: It provides a fully managed file transfer service that eliminates the need to manage your own file transfer infrastructure. This reduces operational overhead. It supports multiple protocols like SFTP, FTPS, FTP and AS2, allowing easy and secure exchange of data with business partners and customers. File transfers happen directly into Amazon S3 buckets or Amazon EFS file systems, so the transferred data can be easily accessed by other AWS services for analytics, processing etc. AWS Transfer Family maintains existing client-side configurations, so file transfer workflows remain unchanged for end users and partners. It provides high availability and auto-scaling capabilities to handle varying transfer workloads.
Comment: Storing transferred files in AWS allows using a broad range of services for compliance, archiving and deriving insights from the data. AWS manages the file transfer infrastructure so you don't have to provision, operate and maintain file transfer servers. For more details on AWS Transfer Family features, pricing and quotas, please refer to the documentation at https://aws.amazon.com/transfer-family
Comment: Amazon S3 File Gateway, involves deploying an on-premises gateway that interfaces with S3. While it's a valid solution, it introduces a level of on-premises infrastructure that may require more operational management.
Comment: AWS Transfer Family securely scales your recurring business-to-business file transfers to AWS Storage services using SFTP, FTPS, FTP, and AS2 protocols.
Comment: A is the correct answer. AWS Transfer Family provides a fully managed SFTP service that can integrate directly with S3. It handles scaling, availability, and security automatically with minimal overhead.
Comment: AWS Transfer Family is a fully managed service that makes it easy to set up and manage secure file transfers. It provides a high-availability SFTP server that can be accessed from the public internet. However, this solution does not minimize operational overhead, as it requires the solutions architect to manage the SFTP server.
Comment: This solution provides a highly available SFTP solution without the need for manual management or operational overhead. AWS Transfer Family allows you to easily set up an SFTP server with authentication, authorization, and integration with S3 as the storage backend. Option B is not the best choice as it suggests using Amazon S3 File Gateway, which is primarily used for file-based access to S3 storage over NFS or SMB protocols, not for SFTP access. Option C is not the best choice as it requires manual management of an EC2 instance, VPN setup, and cron job script for uploading files, introducing operational overhead and potential complexity. Option D is not the best choice as it also requires manual management of EC2 instances, Network Load Balancer, and cron job scripts for file uploads. It is more complex and involves additional components compared to the simpler and fully managed solution provided by AWS Transfer Family in option A.
Comment: This solution provides a highly available SFTP solution without the need for manual management or operational overhead. AWS Transfer Family allows you to easily set up an SFTP server with authentication, authorization, and integration with S3 as the storage backend. Option B is not the best choice as it suggests using Amazon S3 File Gateway, which is primarily used for file-based access to S3 storage over NFS or SMB protocols, not for SFTP access. Option C is not the best choice as it requires manual management of an EC2 instance, VPN setup, and cron job script for uploading files, introducing operational overhead and potential complexity. Option D is not the best choice as it also requires manual management of EC2 instances, Network Load Balancer, and cron job scripts for file uploads. It is more complex and involves additional components compared to the simpler and fully managed solution provided by AWS Transfer Family in option A.
Comment: A is correct
Comment: I can't wrap my head around why the answer is D? this is so frustrating to see where i went wrong. I vote for A.
Comment: minimizes operational overhead = Serverless AWS Transfer Family is serverless
Comment:
AWS Transfer Family is compatible for SFTP
Comment: AWS Transfer Family is a fully managed AWS service that you can use to transfer files into and out of Amazon Simple Storage Service (Amazon S3) storage or Amazon Elastic File System (Amazon EFS) file systems over the following protocols: Secure Shell (SSH) File Transfer Protocol (SFTP): version 3 File Transfer Protocol Secure (FTPS) File Transfer Protocol (FTP) Applicability Statement 2 (AS2)
Comment: A - is the correct answer.
Comment: A -- is the option
Comment: Option A
Comment: Originally answered B and C due to least operational overhead. after research its bugging me that the s3 key rotation is determined based on AWS master Key rotation which cannot guarantee the key is rotated with in a 365 day period. stated as "varies" in the documentation. also its impossible to configure this in the console. KMS-C is a tick box in the console to turn on annual key rotation but requires more operational overhead than SSE-S3. C - will not guarantee the questions objectives but requires little overhead. D - will guarantee the questions objective with more overhead.
Comment: I‘d have to disagree on that. It states here that aws managed keys are rotated every year which is what the question asks: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html so C would be correct. However, it also states that you cannot enable or disable rotation for aws managed keys which would again point towards D
Comment: You can't use this link https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html to said that "sse-s3" rotates every year, cos' preciselly that link refers to "KMS", that is covered with option D. That the reason the solution is B+D.
Comment: should be BD C could have been fine, but key rotation is activate per default on SSE-S3, and no way to deactivate it if I am not wrong
Comment: For me it is B and C. C because it does everything automatically and this is the requirement. (with LEAST operational overhead)
Comment: S3 Object Lock can help prevent Amazon S3 objects from being deleted or overwritten for a fixed amount of time or indefinitely. In compliance mode, a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account.
Comment: BD for sure
Comment: basically what that pentium75 guy said - correct.
Comment: "Least operational overhead": C
Comment: C- you don't have control over rotation schedule for SSE-S3
Comment: B. Using S3 Object Lock in compliance mode ensures that the documents cannot be substituted or deleted during the specified retention period, which in this case is 5 years. This helps meet the requirement of ensuring the documents remain immutable for the duration of the contract. D. Using server-side encryption with AWS Key Management Service (AWS KMS) customer managed keys allows for encryption of the documents at rest. Additionally, configuring key rotation for the customer managed keys ensures that the encryption keys are automatically rotated every year, meeting the requirement of rotating encryption keys automatically.
Comment: Answer: BD: B: S3 Compliance Mode ensures no one can overwrite or delete the object. D: Customer-managed KMS Key: (must be enabled) automatic every 1 year Options not right: A: Governance mode allows override and delete. C: SSE-S3 customer do not have control on rotation of keys(Which is once a year in our requirement) E: As per AWS Documentation, Customer Imported keys cannot be auto rotated.
Comment: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
Comment: The best option to encrypt data at rest in Amazon S3 and rotate the keys every year is to use AWS KMS (Key Management Service). With AWS KMS: You can create a customer master key (CMK) and schedule automatic key rotation every year. This ensures the data is encrypted with a new key annually. When storing objects in S3, you can choose server-side encryption with AWS KMS (SSE-KMS). This will encrypt the data with the CMK you created. Even if the encrypted data is copied or transferred, it will remain encrypted since the keys are managed by KMS. You have full control over the keys and can define IAM policies for key access. AWS manages the encryption, key operations and auditing through integrated services like CloudTrail. It provides an end-to-end encryption solution within AWS without needing to handle encryption/decryption yourself.
Comment: THIS WAS IN MY EXAM
Comment: A - Governance mode allows exceptions B - Yes C - SSE-S3 rotates keys when AWS thinks is right, not when customer wants ("every year") D - Yes E - "customer provided (imported) keys" can obviously not be 'rotated automatically', the customer would have to provide/import new keys.
Comment: KMS indeed rotates keys every year, but the reason why C is wrong is that the Amazon managed keys can't be configured to rotate or not. REF: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-keys-how-it-works
Comment: Agree with pentium75
Comment: File cannot be overwitten = s3 compliance mode encryption AT REST = user-side encryption
Comment: so the correct answer is BD
Comment: user side encryption?
Comment: File cannot be overwitten = compliance mode Encryption AT REST = user-side encryption
Comment: Question might be outdated. Amazon S3 now automatically applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the default encryption for all buckets since January 5, 2023. Additionally, it encrypts the key itself with another key that undergoes regular rotation, enhancing security. Regarding key rotation, the document specifies that the key used to encrypt the S3 Encryption Key undergoes regular rotation. However, it does not explicitly mention the rotation frequency or the ability to customize it. Therefore, considering the requirement for key rotation and the lack of explicit details about rotation frequency, options B and D would be suitable choices.
Comment: B. Provides a highly available and managed solution with minimum operational overhead. By deploying the web application to EBS, the infrastructure and platform management are abstracted, allowing easy deployment and scalability. With URL swapping, different environments can be created for testing new site features, and traffic can be routed between these environments without any downtime. A. Suggests using S3 for static content hosting and Lambda for dynamic content. While it offers simplicity for static content, it does not provide the necessary flexibility and dynamic functionality required by a Java and PHP-based web application. C. Involves manual management of EC2, ASG, and ELB, which requires more operational overhead and may not provide the desired level of availability and ease of testing. D. Introduces containerization, which adds complexity and operational overhead for managing containers and infrastructure, making it less suitable for a requirement of minimum operational overhead.
Comment: B Elastic Beanstalk is a fully managed service that makes it easy to deploy and run applications in the AWS; To enable frequent testing of new site features, you can use URL swapping to switch between multiple Elastic Beanstalk environments.
Comment: The correct answer is D. AWS Elastic Beanstalk is a service that makes it easy to deploy and manage web applications in the AWS cloud. However, it is not a good solution for testing new site features frequently, as it can be difficult to switch between multiple Elastic Beanstalk environments.
Comment: Containers allow you test your app in isolated environments, therefore D is the correct option.
Comment: B - Because AWS Elastic Beanstalk performs an in-place update when you update your application versions, your application might become unavailable to users for a short period of time. To avoid this, perform a blue/green deployment. To do this, deploy the new version to a separate environment, and then swap the CNAMEs of the two environments to redirect traffic to the new version instantly.
Comment: Elastic Beanstalk can test Blue/Green deployment. Switching Dev to prod/ prod to dev easily.
Comment: A and C are not allowing for feature testing. B and D allow feature testing. D requires overhead of containerisation as well as the LB controller to selectively chose containers for features (assuming on how this might be implemented). EBS allows switching between environment like A/B testing but on whole site. Expensive but cost is not a concern for this question.
Comment: WS Elastic Beanstalk supports multiple environments, but each environment can only run one platform at a time. A platform is a combination of an operating system, runtime, and web server, and in this case, Java and PHP would be considered different platforms. So, if you want to use both Java and PHP, you would need to create two separate environments, one for each. You can then link these environments together using AWS services like Route 53 for routing traffic, or use an Application Load Balancer to distribute incoming traffic between the two environments.
Comment: Option B (AWS Elastic Beanstalk): Elastic Beanstalk is a fully managed service that makes it easy to deploy and run applications in multiple languages (including Java and PHP) with MINIMAL OPERATION OVERHEAD. It abstracts the infrastructure management, allowing you to focus on your application. URL swapping in Elastic Beanstalk allows you to easily switch between different environments, making it convenient for testing new features.
Comment: B Elastic Beanstalk is a fully managed service that makes it easy to deploy and run applications in the AWS; To enable frequent testing of new site features, you can use URL swapping to switch between multiple Elastic Beanstalk environments. https://docs.aws.amazon.com/zh_tw/whitepapers/latest/blue-green-deployments/swap-the-environment-of-an-elastic-beanstalk-application.html
Comment: B Elastic Beanstalk is a fully managed service that makes it easy to deploy and run applications in the AWS; To enable frequent testing of new site features, you can use URL swapping to switch between multiple Elastic Beanstalk environments. https://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html
Comment: AWS Elastic Beanstalk URL swapping is the main ask of this question.
Comment: B is the correct answer. Using AWS Elastic Beanstalk provides a fully managed platform to deploy the web application. Elastic Beanstalk will handle provisioning EC2 instances, load balancing, auto scaling, and application health monitoring. Elastic Beanstalk's ability to support multiple environments and swap URLs allows easy testing of new features before swapping into production. This requires minimal overhead compared to managing infrastructure directly.
Comment: The correct answer is D. AWS Elastic Beanstalk is a service that makes it easy to deploy and manage web applications in the AWS cloud. However, it is not a good solution for testing new site features frequently, as it can be difficult to switch between multiple Elastic Beanstalk environments.
Comment: S3 is for hosting static websites not dynamic websites or applications Beanstalk will take care of this.
Comment: Frequent feature testing - - Multiple Elastic Beanstalk environments can be created easily for development, testing and production use cases. - Traffic can be routed between environments for A/B testing and feature iteration using simple URL swapping techniques. No complex routing rules or infrastructure changes required.
Comment: who needs discussion in the era the of chatGPT
Comment: In the era of ChatGPT, individuals across education, business, content creation, healthcare, programming, language learning, innovation, and mental health benefit from discussions. Students, professionals, writers, developers, language learners, innovators, and those seeking support find ChatGPT valuable for learning, problem-solving, creative endeavors, and companionship. It serves as a versatile tool for information, collaboration, and engagement across diverse domains, enhancing communication in an accessible and interactive manner.
Comment: chatGPT always change its answer. just say wrong answer, he will come up with new answer each time with justification. chatGPT is not trusted at all.
Comment: Option B as it has the minimum operational overhead
Comment: A is correct answer. This was in my exam
Comment: Did these questions help with your exam?
Comment: The best solution to address the timeouts and eliminate the impact of long-running reporting queries without disrupting order processing is:A
Comment: Reporting queries will point to read replica. Application will still point to primary db for write / read operations.
Comment: The correct answer to this question is A: Create a read replica. Move reporting queries to the read replica. This solution is designed to alleviate the load on the primary database used by the ordering application. By offloading the reporting queries to a read replica, the primary instance is freed up to handle operational transactions like order processing without contention from the resource-intensive reporting queries. This should effectively reduce or eliminate the timeouts currently experienced during order processing.
Comment: create the replica and all the report queries get data from that read replica.
Comment: B incorrect because ordering application needs to write data to the DB.
Comment: A. By moving the reporting queries to the read replica, the primary DB instance used for order processing is not affected by the long-running reporting queries. This helps eliminate timeouts during order processing while allowing employees to perform their queries without impacting the application's performance. B. While this can provide some level of load distribution, it does not specifically address the issue of timeouts caused by reporting queries during order processing. C. While DynamoDB offers scalability and performance benefits, it may require significant changes to the application's data model and querying approach. D. While this approach can help alleviate the impact on order processing, it does not address the requirement of eliminating timeouts without preventing employees from performing queries.
Comment: "A" is correct because is does not cause problems in the primary DB
Comment: reports = read replica
Comment: A is the correct answer. Creating an RDS MySQL read replica will allow the reporting queries to be isolated and run without affecting performance of the primary ordering application. Read replicas allow read-only workloads to be scaled out while eliminating contention with the primary write workload.
Comment: Question keyword "regular business hours" made D is incorrect. C migrate to Amazon DynamoDB (No-SQL) is meaningless, remove C. Answer B, create a "read replica", it is ok, but "ordering application pointed to read replica" is incorrect. A is correct answer. Easy question.
Comment: A sounds right
Comment: Using the primary instance continues with the problem
Comment: A. By moving the reporting queries to the read replica, the primary DB instance used for order processing is not affected by the long-running reporting queries. This helps eliminate timeouts during order processing while allowing employees to perform their queries without impacting the application's performance. B. While this can provide some level of load distribution, it does not specifically address the issue of timeouts caused by reporting queries during order processing. C. While DynamoDB offers scalability and performance benefits, it may require significant changes to the application's data model and querying approach. D. While this approach can help alleviate the impact on order processing, it does not address the requirement of eliminating timeouts without preventing employees from performing queries.
Comment: correct
Comment: A is correct.
Comment: Creating a read replica allows the company to offload the reporting queries to a separate database instance, reducing the load on the primary database used for order processing. By moving the reporting queries to the read replica, the ordering application running on the primary DB instance can continue to process orders without timeouts due to the long-running reporting queries. Option B is not a good solution because distributing the ordering application to the primary DB instance and the read replica does not address the issue of long-running reporting queries causing timeouts during order processing.
Comment: B and E are correct. Textract to extract text from files. Rekognition can also be used for text detection but after Rekognition - it's mentioned that Transcribe is used. Transcribe is used for Speech to Text. So that option D may not be valid.
Comment: no brainer: B,E
Comment: E: Amazon Textract & Amazon Comprehend Medical obviously do the job with least operational overhead. D can do this but it will be extra work and overhead. B for running SQL queries on S3 bucket directly without extra overhead.
Comment: Write the document information to an Amazon S3 bucket. Use Amazon Athena to query the data. Create an AWS Lambda function that runs when new documents are uploaded. Use Amazon Textract to convert the documents to raw text. Use Amazon Comprehend Medical to detect and extract relevant medical information from the text.
Comment: another mistake from the admin, should correct this one, because we all agree
Comment: Answer - BE Option D mentions using Amazon Rekognition and Amazon Transcribe Medical, which are primarily designed for image and audio analysis, respectively. While they can be part of a document processing pipeline, Amazon Textract and Amazon Comprehend Medical are more suitable for extracting structured information from documents, making option E a better choice.
Comment: Write the document information to an Amazon S3 bucket. Use Amazon Athena to query the data. Create an AWS Lambda function that runs when new documents are uploaded. Use Amazon Textract to convert the documents to raw text. Use Amazon Comprehend Medical to detect and extract relevant medical information from the text.
Comment: B and E are the correct answers. B is correct because storing the scanned documents in Amazon S3 provides highly scalable and durable storage. Amazon Athena allows running SQL queries directly against the data in S3 without needing to load the data into a database. E is correct because using Lambda functions triggered by uploads provides a serverless approach to automatically process each document. Amazon Textract and Comprehend Medical can extract text and medical information without needing to manage server
Comment: Amazon Comprehend Medical for image reading https://aws.amazon.com/comprehend/medical/ . Amazon Transcribe Medical for speech audio. Remove D. Keep E. A is meaningless, remove A (EC2). B use Amazon S3, Athena for querying, keep B. Conclusion combination B and E are correct answers.
Comment: AC wrong as involve EC2. Either one of DE are correct so that makes B correct. Now E is obvious answer if we have read AWS FAQs
Comment: Textract to extract the content and Athena to run sql queries on S3 data
Comment: From a DE/ML perspective Lambda + Textract + S3 + Athena is the best way to go
Comment: Transcribe is used. Transcribe is used for Speech to Text
Comment: B is correct because it suggests writing the document information to an Amazon S3 bucket, which provides scalable and durable object storage. Using Amazon Athena, the data can be queried using SQL, enabling efficient analysis. E is correct because it involves creating an AWS Lambda function triggered by new document uploads. Amazon Textract is used to convert the documents to raw text, and Amazon Comprehend Medical extracts relevant medical information from the text. A is incorrect because writing the document information to an Amazon EC2 instance with a MySQL database is not a scalable or efficient solution for analysis. C is incorrect because creating an Auto Scaling group of Amazon EC2 instances for processing scanned files and extracting information would introduce unnecessary complexity and management overhead. D is incorrect because using an EC2 instance with a MySQL database for storing document information is not the optimal solution for scalability and efficient analysis.
Comment: It states in the question that the written documents are scanned. They are converted into images after being scanned. Rekognition would be best to analyse images.
Comment: Options B & E are correct answers.
Comment: Why CD are marked as correct??
Comment: Use ElastiCache to reduce reading and choose redis to ensure high availability.
Comment: Where is the high availability when the database fails and the cache time runs out? The answer is a.
Comment: Elasticache for Redis ensures high availability by using read replicas and Multi AZ with failover. It is also faster since it uses cache. https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/AutoFailover.html
Comment: Right here: Redis has Multi AZ with Auto-Failover (in addition it got Read Replicas for HA)
Comment: THE FOCUS HERE IS TO REDUCE READ OPERATION FROM THE READ REPLICAS. CATCHING IS THE SOLUTION AND REDIS IS MOST SUITABLE
Comment: They run multiple databases
Comment: Caching Frequently Accessed Data: ElastiCache allows you to store frequently accessed or computationally expensive data in-memory within the cache nodes. This means that when an application requests data, ElastiCache can provide the data directly from the cache without having to query the RDS database. This reduces the number of reads on the RDS database because the data is retrieved from the faster in-memory cache.
Comment: A vs B: A: reduce the number of database reads on main + high availability provide B: only reduce the number of DB reads so A wins
Comment: Why "only reduce the number of DB reads"? This is exactly what is asked. Elasticache for Redis can be HA (contrary to Elasticache for Memcached).
Comment: pentium75 is right.
Comment: This question is stupid! Both answers can be correct!
Comment: for high availability, the answer should be A
Comment: RDS read replicas are mainly used for higher performance, and not for higher availability, that's why I chose ElastiCache using Redis.
Comment: I Vote B since question is asking to reduce the database reads. Using Read replicas offloads the reading operation from main db but doesn't reduce it.
Comment: B is not correct. the effectiveness of caching depends on the application. it's not always a good solution.
Comment: why not read replica when you get read performant with HA?
Comment: Options B, C, and D are not directly related to ensuring high availability
Comment: I think it is B: https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/ Although the question just says "RDS Database", it doesn't specify what type of DB.
Comment: Elasticahe is NOSQL, A is the Answer!
Comment: Pretty sure answer is option B. You have to use a caching to 'reduce' database reads so read replica is out of option. The question mentions High availability so Redis is preferable than MemCached.
Comment: the question is clearly says reduce reads request, so b is the naswer
Comment: Use ElastiCache to reduce reading and ensure high availability. Opt A read replica its for performance not HA I will vote for B
Comment: the answer should be A, read replicas enhance high availability by providing failover capabilities in case the primary instance becomes unavailable.
Comment: I think A should have been correct if the question had requested for a cost -effective solution because Redis costs money.
Comment: AvsB A:Creating read replicas will ensure the availability of the DB. (CORRECT) B: Will reduce the reading and what happens when there is more reads.
Comment: A. Add Amazon RDS read replicas. Amazon RDS read replicas allow you to create one or more read-only copies of your RDS database instance. By offloading read traffic to read replicas, you can distribute the workload across multiple database instances, reducing the load on the primary database and decreasing the number of reads it needs to handle. This helps to improve the overall performance and scalability of your application.
Comment: Changing my vote to A. After reviewing a Udemy course of SAA-C03, it seems that A (multi-AZ and Clusters) is sufficient for HA.
Comment: what number of class ?
Comment: Here AWS defines HA, and uses the word cluster - AWS has several methods for achieving HA through both approaches, such as through a scalable, load balanced cluster or assuming an active–standby pair. - https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/high-availability-and-scalability-on-aws.html
Comment: The question states that it is a critical app and it has to be HA. A could be the answer, but it's in the same AZ, so if the entire region fails, it doesn't cater for the HA requirement. However, the likelihood of a failure in two different regions at the same time is 0. Therefore, to me it seems that C is the better option to cater for HA requirement. In addition, C does state like A that the DB app is installed on an EC2 instance.
Comment: Option C proposes launching two EC2 instances in different AWS Regions and setting up database replication, with failover to a second Region. While this solution does provide geographic redundancy, it may introduce higher latency due to cross-region communication and data replication. Additionally, failover to a different Region typically involves more complex configurations and longer recovery times compared to failover within the same Region. While Option C may offer a level of redundancy, it might not provide the same level of responsiveness and automatic failover capabilities as Option A, which leverages Availability Zones within the same Region. In scenarios where low latency and rapid failover are critical, Option A is often preferred. However, if geographic redundancy is a top priority and the potential trade-offs in latency and failover time are acceptable, Option C could still be a viable solution.
Comment: but for C you need communication between the two VPC, which increase the complexity. With a should be enough for HA
Comment: The question doesn't ask which option is the most HA. It asks what meets the requirements.
Comment: Design for region failure? may as well design for AWS failure and put replica in GCP and Azure :v
Comment: And on-prem in multiple DCs and one in mars too :D
Comment: yep lol, even in the other questions, for HA you can use Multi-AZ
Comment: this is reading comprehension exam not a practical exam.
Comment: I am voting for A.
Comment: It's a due to being in the same region different AZ for latency purposes.
Comment: A provides HA with 2 EC2 in two AZ with database replication
Comment: C for sure
Comment: What does "Configure the EC2 instances as a cluster" mean? The only "EC2 cluster" that I am aware of is a "cluster placement group". If that's the case, then all EC2 instances in that cluster must be in the same AZ. So option A would be invalid then.
Comment: Option B uses an AMI for backup and CloudFormation for automation, but doesn't provide high availability or automatic failover. Option C launches instances in different regions, which may not be necessary and may increase costs. Option D uses EC2 automatic recovery, which can recover an instance, but doesn't provide high availability or automatic failover.
Comment: The term "disruptive event" implies it requires DR, HA is not sufficient.
Comment: Explanation: Option C provides a solution that ensures high availability by deploying EC2 instances in different AWS Regions. By setting up database replication and failing over the database to a second Region, you ensure automatic failover if a disruptive event occurs in one Region. Options A and B focus on high availability within a single AWS Region but don't address automatic failover to a different Region in case of a disruptive event. Option D uses EC2 automatic recovery, but it doesn't provide a solution for automatic failover to a different Region, which is necessary for ensuring high availability in case of a Region-wide failure.
Comment: C - I am a littel be wonder reading same explanation, becouse exist a vary big differance beetwen instance cluster and dababase cluster.
Comment: Option A suggests deploying two EC2 instances, each in a different Availability Zone within the same AWS Region. This ensures high availability by distributing the instances across multiple physically isolated locations. By installing the database on both EC2 instances and configuring them as a cluster, you create a highly available database setup where one instance can seamlessly take over if the other instance fails. Additionally, setting up database replication between the instances ensures data consistency and redundancy. If one instance fails, the other instance can continue serving requests without interruption.
Comment: A is for HA. D is for DR
Comment: Perfect Answer is A
Comment: A. High Availability - multiple Zones. Disaster Recovery - multiple Regions.
Comment: C "if a disruptive event occurs"
Comment: Answer is C, because question mentioned about disruptive event occurs. when the whole region failed, it can not cover the scenario for HA
Comment: The key reasons are: Using an Auto Scaling group ensures the EC2 instances that process orders are highly available and scalable. With SQS, the orders are decoupled from the instances that process them via asynchronous queuing. If instances fail or go down, the orders remain in the queue until new instances can pick them up. This provides automated resilience. Any failed processing can retry by resending messages back to the queue
Comment: A uses ECS tasks for something which makes no sense. B does not solve the reliable processing of orders C SQS for sending a message and processing it reliable D is like reinventing SQS with SNS and Lambda mumbo jumbo
Comment: How does SNS capture the requests after the application fails? Those messages are ephemeral by nature and will not hold the data like SQS would. In theory one could create a subscription based service using SNS to stream the data to a service that could store the request, but why...
Comment: That's one of the reasons why D is wrong (not to mention the "Systems Manager Run Command" nonsense).
Comment: I stopped reading option D after SNS and Lambda.... it was sounding nonsense. SQS is default reliability delivery system for me.
Comment: it's C... 4 answers wrong I have found
Comment: C. Option D suggests using Amazon SNS and AWS Lambda, which can be part of an event-driven architecture but may not be the best fit for ensuring the automatic processing of orders during system outages. It relies on an additional AWS Systems Manager Run Command step, which adds complexity and may not be as reliable as using SQS for queuing messages.
Comment: "C" because they need to store the request and then be process by the system if it fails, SNS does not have that capacity. another mistake from the admin
Comment: Option D suggests using Amazon SNS and AWS Lambda, which can be part of an event-driven architecture but may not be the best fit for ensuring the automatic processing of orders during system outages. It relies on an additional AWS Systems Manager Run Command step, which adds complexity and may not be as reliable as using SQS for queuing messages.
Comment: Move the EC2 instances into an Auto Scaling group. Configure the order system to send messages to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the EC2 instances to consume messages from the queue.
Comment: C is the correct answer. Using an Auto Scaling group with EC2 instances behind a load balancer provides high availability and scalability. Sending the orders to an SQS queue decouples the ordering system from the processing system. The EC2 instances can poll the queue for new orders and process them even during an outage. Any failed orders will go back to the queue for reprocessing.
Comment: By moving the EC2 into an ASG and configuring them to consume messages from an SQS, the system can decouple the order processing from the order system itself. This allows the system to handle failures and automatically process orders even if the order system or EC2 experience outages. A. Using an ASG with an EventBridge rule targeting an ECS task does not provide the necessary decoupling and message queueing for automatic order processing during outages. B. Moving the EC2 instances into an ASG behind an ALB does not address the need for message queuing and automatic processing during outages. D. Using SNS and Lambda can provide notifications and orchestration capabilities, but it does not provide the necessary message queueing and consumption for automatic order processing during outages. Additionally, using Systems Manager Run Command to send commands for order processing adds complexity and does not provide the desired level of automation.
Comment: D is so unnecessary .... this confuses people
Comment: Thx Allmightly for voting system! Answers provided by the site (and not by community) are 20% wrong.
Comment: The answer D is so complex and unnecessary. Why moderator is not providing an explanation of answers when there are heavy conflicts. These kind of answers put your knowledge in question which is not good going into the exam.
Comment: The "Correct Answers" for this exam are obviously determined by picking a random letter between A and D.
Comment: To meet the company's requirements of having a resilient solution that can process orders automatically in case of a system outage, the solutions architect needs to implement a fault-tolerant architecture. Based on the given scenario, a potential solution is to move the EC2 instances into an Auto Scaling group and configure the order system to send messages to an Amazon Simple Queue Service (Amazon SQS) queue. The EC2 instances can then consume messages from the queue.
Comment: Answer : C
Comment: C. Move the EC2 instances into an Auto Scaling group. Configure the order system to send messages to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the EC2 instances to consume messages from the queue. To meet the requirements of the company, a solutions architect should ensure that the system is resilient and can process orders automatically in the event of a system outage. To achieve this, moving the EC2 instances into an Auto Scaling group is a good first step. This will enable the system to automatically add or remove instances based on demand and availability.
Comment: However, it's also necessary to ensure that orders are not lost if a system outage occurs. To achieve this, the order system can be configured to send messages to an Amazon Simple Queue Service (Amazon SQS) queue. SQS is a highly available and durable messaging service that can help ensure that messages are not lost if the system fails. Finally, the EC2 instances can be configured to consume messages from the queue, process the orders and then store them in the database on Amazon RDS. This approach ensures that orders are not lost and can be processed automatically if a system outage occurs. Therefore, option C is the correct answer.
Comment: Option A is incorrect because it suggests creating an Amazon EventBridge rule to target an Amazon Elastic Container Service (ECS) task. While this may be a valid solution in some cases, it is not necessary in this scenario. Option B is incorrect because it suggests moving the EC2 instances into an Auto Scaling group behind an Application Load Balancer (ALB) and updating the order system to send messages to the ALB endpoint. While this approach can provide resilience and scalability, it does not address the issue of order processing and the need to ensure that orders are not lost if a system outage occurs. Option D is incorrect because it suggests using Amazon Simple Notification Service (SNS) to send messages to an AWS Lambda function, which will then send a command to the EC2 instances to process the messages by using AWS Systems Manager Run Command. While this approach may work, it is more complex than necessary and does not take advantage of the durability and availability of SQS.
Comment: My question is; can orders be sent directly into an SQS queue ? How about the protocol for management of the messages from the queue ? can EC2 instances be programmed to process them like Lambda ?
Comment: I choose D
Comment: and manually send commands through Systems Manager whenever a new order appears?
Comment: changing my answer to D after researching a bit. The DynamoDB TTL feature allows you to define a per-item timestamp to determine when an item is no longer needed. Shortly after the date and time of the specified timestamp, DynamoDB deletes the item from your table without consuming any write throughput.
Comment: Always bet on the TTL
Comment: I would day C Because D requires extending the application to add the timestamp attribute. Which is by itself a development effort.
Comment: It's to minimize development effort. C is not the correct one because it needs to enable Dynamo Streams and configure them to send to Lambda, then create the Lambda code for deleting items. Besides that, the Lambda is triggered only on new items, and since it's ephemeral, it would have to query items older than 30 days and then delete them. With D, you just need to make two small changes, and it's done—no extra service, no overhead, and no concern about failing to remove.
Comment: D is the correct answer
Comment: D is the best answer, dynamostreams is not suitable for this use cases
Comment: Option D is the most suitable solution to meet the company's requirements while minimizing cost and development effort. TTL (Time to Live) Attribute: DynamoDB provides a feature called Time to Live (TTL), which allows you to automatically delete items from a table after a specified period. By adding a TTL attribute to each item with a value of the current timestamp plus 30 days, you can let DynamoDB automatically delete items older than 30 days. This eliminates the need for manual deletion efforts or periodic stack redeployment. Minimal Development Effort Cost-Effective
Comment: use ttl
Comment: A and B don't solve anything. Between C and D, C requires more cost due to Lambda executions. D uses the TTL built-in feature so it won't cost extra. Also, D does not require extra development and is a matter of configuration. In old-school developer speak, don't write code if your DBA can do some work!
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html
Comment: DynamoDB Time to Live was designed to handle this kind of requirement where an item is no longer needed. TTL is provided at no extra cost as a means to reduce stored data volumes by retaining only the items that remain current for your workload's needs
Comment: D. Extend the application to add an attribute that has a value of the current timestamp plus 30 days to each new item that is created in the table. Configure DynamoDB to use the attribute as the TTL attribute. The main reasons are: Using DynamoDB's built-in TTL functionality is the most direct way to handle data expiration. It avoids the complexity of triggers, streams, and lambda functions in option C. Modifying the application code to add the TTL attribute is relatively simple and minimizes operational overhead
Comment: By adding a TTL attribute to the DynamoDB table and setting it to the current timestamp plus 30 days, DynamoDB will automatically delete the items that are older than 30 days. This solution eliminates the need for manual deletion or additional infrastructure components. A. Redeploying the CloudFormation stack every 30 days and deleting the original stack introduces unnecessary complexity and operational overhead. B. Using an EC2 instance with a monitoring application and a script to delete items older than 30 days adds additional infrastructure and maintenance efforts. C. Configuring DynamoDB Streams to invoke a Lambda function to delete items older than 30 days adds complexity and requires additional development and operational effort compared to using the built-in TTL feature of DynamoDB.
Comment: D: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html
Comment: Amazon DynamoDB Time to Live (TTL) allows you to define a per-item timestamp to determine when an item is no longer needed.
Comment: C is incorrect because it can take more than 15 minutes to delete the old data. Lambda won't work
Comment: Clear case for TTL - every object gets deleted after a certain period of time
Comment: Use DynamoDB TTL feature to achieve this..
Comment: C is absurd. DynamoDB usually is a RDS with high iops (read/write operations on tables), executing a Lambda function eachtime you insert a item will not be cost-effective.It's much better create such a field the question propose, and manage the delete with a SQL delete sentence: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.DeleteData.html
Comment: B. Rehost the application in AWS Elastic Beanstalk with the .NET platform in a Multi-AZ deployment. E. Use AWS Database Migration Service (AWS DMS) to migrate from the Oracle database to Oracle on Amazon RDS in a Multi-AZ deployment. Rehosting the application in Elastic Beanstalk with the .NET platform can minimize development changes. Multi-AZ deployment of Elastic Beanstalk will increase the availability of application, so it meets the requirement of high availability. Using AWS Database Migration Service (DMS) to migrate the database to Amazon RDS Oracle will ensure compatibility, so the application can continue to use the same database technology, and the development team can use their existing skills. It also migrates to a managed service, which will handle the availability, so the team do not have to worry about it. Multi-AZ deployment will increase the availability of the database.
Comment: DynamoDB is NoSQL - E it out Replatform requires considerable overhead - C is out Lambda function is for running code for short duration - A is out Answer - BE
Comment: BE = least effort approach.. basically a lift and shift which is what the questions is asking for
Comment: d - incorrect at all. Doesn't exist way for migration oracle to dinamoDB.
Comment: E for minimizing development changes by using same Oracle engine but in highly available deployment. C and D require platform change so it won't work as it increases development. A is also development work of converting .Net to .Net core Lambda functions. May not even be possible. B is simple lift and shift BE is correct
Comment: Minimize development changes + High availability = AWS Elastic Beanstalk and Oracle on Amazon RDS in a Multi-AZ deployment
Comment: B) Rehost the application in AWS Elastic Beanstalk with the .NET platform in a Multi-AZ deployment. E) Use AWS Database Migration Service (AWS DMS) to migrate from the Oracle database to Oracle on Amazon RDS in a Multi-AZ deployment. The reasons are: ° Rehosting in Elastic Beanstalk allows lifting and shifting the .NET application with minimal code changes. Multi-AZ deployment provides high availability. ° Using DMS to migrate the Oracle data to RDS Oracle in Multi-AZ deployment minimizes changes for the database while achieving high availability. ° Together this "lift and shift" approach minimizes refactoring needs while providing HA on AWS.
Comment: B. This allows the company to migrate the application to AWS without significant code changes while leveraging the scalability and high availability provided by EBS's Multi-AZ deployment. E. This enables the company to migrate the Oracle database to RDS while maintaining compatibility with the existing application and leveraging the Multi-AZ deployment for high availability. A. would require significant development changes and may not provide the same level of compatibility as rehosting or replatforming options. C. would still require changes to the application and the underlying infrastructure, whereas rehosting with EBS minimizes the need for modification. D. would likely require significant changes to the application code, as DynamoDB is a NoSQL database with a different data model compared to Oracle.
Comment: Answer is BE. No idea why D was chosen. That requires development work and question clearly states minimize development changes, changing db from Oracle to DynamoDB is LOT of development.
Comment: B + E are the anwers that fulfil the requirements.
Comment: B and E
Comment: why not C?
Comment: Retire(simplest) < Retain < Relocate < Rehost < Repurchase < Replatform < Re-architect/Refactor (most complex)....So by this order rehosting less complex than replatform thats why we go for BE
Comment: It runs on a windows server, shifting the whole this to Linux based EC2 would be extra work and of no sense
Comment: Answer : BE
Comment: Why A is wrong?
Comment: Because that needs some development,
Comment: B. Rehost the application in AWS Elastic Beanstalk with the .NET platform in a Multi-AZ deployment. E. Use AWS Database Migration Service (AWS DMS) to migrate from the Oracle database to Oracle on Amazon RDS in a Multi-AZ deployment. To minimize development changes while moving the application to AWS and to ensure a high level of availability, the company can rehost the application in AWS Elastic Beanstalk with the .NET platform in a Multi-AZ deployment. This will allow the application to run in a highly available environment without requiring any changes to the application code. The company can also use AWS Database Migration Service (AWS DMS) to migrate the Oracle database to Oracle on Amazon RDS in a Multi-AZ deployment. This will allow the company to maintain the existing database platform while still achieving a high level of availability.
Comment: B&E Option ,because D is for No-Sql
Comment: And requires additional development effort
Comment: B&E Option
Comment: If you see MongoDB, just go ahead and look for the answer that says DocumentDB.
Comment: Option D is the correct solution that meets all the requirements: º Use Amazon Elastic Kubernetes Service (Amazon EKS) with AWS Fargate for compute and Amazon DocumentDB (with MongoDB compatibility) for data storage. The key reasons are: º EKS allows running the Kubernetes environment on AWS without changes. º Using Fargate removes the need to provision and manage EC2 instances. º DocumentDB provides MongoDB compatibility so the data layer is unchanged.
Comment: Applications are already containerized. Amazon EKS is fully managed kubernetes service. FarGate = Less overhead of managing infrastructure. Amazon DocumentDB is MongoDB Compatible. Answer D
Comment: no brainer says D
Comment: Question keyword "containerized application", "Kubernetes cluster", "no changes or deployment method changes". Choose C, not D. But "minimizes operational overhead", choose D.
Comment: This solution allows the company to leverage EKS to manage the K8s cluster and Fargate to handle the compute resources without requiring manual management of EC2 worker nodes. The use of DocumentDB provides a fully managed MongoDB-compatible database service in AWS. A. would require managing and scaling the EC2 instances manually, which increases operational overhead. B. would require significant changes to the application code as DynamoDB is a NoSQL database with a different data model compared to MongoDB. C. would also require code changes to adapt to DynamoDB's different data model, and managing EC2 worker nodes increases operational overhead.
Comment: The solution meets these requirements is option D.
Comment: minimizes operational overhead = Serverless (Fargate) MongoDB = DocumentDB
Comment: To minimize operational overhead and avoid making any code or deployment method changes, the company can use Amazon Elastic Kubernetes Service (EKS) with AWS Fargate for computing and Amazon DocumentDB (with MongoDB compatibility) for data storage. This solution allows the company to run the containerized application on EKS without having to manage the underlying infrastructure or make any changes to the application code. AWS Fargate is a fully-managed container execution environment that allows you to run containerized applications without the need to manage the underlying EC2 instances. Amazon DocumentDB is a fully-managed document database service that supports MongoDB workloads, allowing the company to use the same database platform as in their on-premises environment without having to make any code changes.
Comment: Reason A &B Elimnated as its Kubernates why D read here https://containersonaws.com/introduction/ec2-or-aws-fargate/
Comment: Option D
Comment: DDDDDDD
Comment: https://www.examtopics.com/discussions/amazon/view/67897-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: D meets the requirements
Comment: D EKS because of Kubernetes so A and B are eliminated not C because of MongoDB and Fargate is more expensive
Comment: The correct answer is B: Use Amazon Transcribe for multiple speaker recognition. Use Amazon Athena for transcript file analysis. Amazon Transcribe is a service that automatically transcribes spoken language into written text. It can handle multiple speakers and can generate transcript files in real-time or asynchronously. These transcript files can be stored in Amazon S3 for long-term storage. Amazon Athena is a query service that allows you to analyze data stored in Amazon S3 using SQL. You can use it to analyze the transcript files and identify patterns in the data. Option A is incorrect because Amazon Rekognition is a service for analyzing images and videos, not transcribing spoken language. Option C is incorrect because Amazon Translate is a service for translating text from one language to another, not transcribing spoken language. Option D is incorrect because Amazon Textract is a service for extracting text and data from documents and images, not transcribing spoken language.
Comment: The correct answer is C. https://docs.aws.amazon.com/transcribe/latest/dg/what-is.html You can transcribe streaming media in real time or you can upload and transcribe media files. To see which languages are supported for each type of transcription, refer to the Supported languages and language-specific features table.
Comment: Disregard. I meant B
Comment: https://aws.amazon.com/about-aws/whats-new/2022/06/amazon-transcribe-supports-automatic-language-identification-multi-lingual-audio/ Amazon Translate is a service for multi-language identification, which identifies all languages spoken in the audio file and creates transcript using each identified language.
Comment: Disregard. I meant Amazon Transcribe
Comment: What bothers me is the 7 years of storage.
Comment: Option B is the most relevant one, but it doesn't mention how to retain data in 7 years...
Comment: This is a poorly worded question with poorly worded options. Rekognition and Translate cannot convert speech to text so those options A, C & D are gone. B is the closes option but it does not mention S3 or retention policy of 7 years. Just a best guess on massive assumptions.
Comment: check out this blog here: https://aws.amazon.com/de/blogs/machine-learning/automating-the-analysis-of-multi-speaker-audio-files-using-amazon-transcribe-and-amazon-athena/
Comment: Perfectly explained here: https://aws.amazon.com/de/blogs/machine-learning/automating-the-analysis-of-multi-speaker-audio-files-using-amazon-transcribe-and-amazon-athena/
Comment: really hope I could have this kind of question during the exam, 4 different techs in the first 5 words of the answer! Just go with the correct one and ignore the rest of the text XDDD
Comment: https://aws.amazon.com/blogs/machine-learning/automating-the-analysis-of-multi-speaker-audio-files-using-amazon-transcribe-and-amazon-athena/
Comment: Amazon Rekognition is primarily designed for image and video analysis, not for transcribing audio or recognizing multiple speakers. -> Option A and D are ruled out Amazon Translate is used for language translation -> Option C is ruled out
Comment: Provide multiple speaker recognition and generate transcript files = Amazon Transcribe Query the transcript files = Amazon Athena
Comment: The correct answer is B: Use Amazon Transcribe for multiple speaker recognition. Use Amazon Athena for transcript file analysis.
Comment: Tricky or incomplete question.. B is the answer because Transcribe is the right service for processing voice calls. But 7 years of storage is not covered (should add S3 storage) And Athena querying is just SQL querying, it cannot help you much to recognize business patterns, for that I would think some text analysis service like Comprehend would be needed. Unless... We use Transcribe not only to transcribe, but also to recognize some key words, and then create a DB/S3 record with multiple fields, e.g. if it is a telemarketing questionnaire, record answer for each question. Then SQL querying might be useful.
Comment: "The company wants to query the transcript files" is the requirement. How they will be using the query results "to analyze the business patterns" is not our issue. The "7 years" are not mentioned in any of the options, but Transcribe stores results in S3.
Comment: Transcribe and (s3) + Athena is the way to go here. Redshift sounds like an overkill
Comment: Amazon Transcribe provides accurate transcription of audio recordings with multiple speakers, generating transcript files. These files can be stored in Amazon S3. To analyze the transcripts and extract insights, Amazon Athena allows SQL-based querying of the stored files. A. Amazon Rekognition is for image and video analysis, not audio transcription. C. Amazon Translate is for language translation, not speaker recognition or transcript analysis. Amazon Redshift may not be the best choice for storing and querying transcript files. D. Amazon Rekognition is for image and video analysis, and Amazon Textract is for document extraction, not suitable for audio transcription or analysis. Storing the transcript files in S3 is appropriate, but the analysis requires a different service like Amazon Athena.
Comment: the solution that meets these requirements is option B.
Comment: B is correct
Comment: Amazon Transcribe is a service that convert speech into text, so B is the answer
Comment: Answer : B
Comment: KEYWORD: LEAST operational overhead To control access to the REST API and reduce development efforts, the company can use an Amazon Cognito user pool authorizer in API Gateway. This will allow Amazon Cognito to validate each request and ensure that only authenticated users can access the API. This solution has the LEAST operational overhead, as it does not require the company to develop and maintain any additional infrastructure or code. Therefore, Option D is the correct answer. Option D. Configure an Amazon Cognito user pool authorizer in API Gateway to allow Amazon Cognito to validate each request.
Comment: Control access to a REST API using Amazon Cognito user pools as authorizer https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
Comment: Answer D By integrating Amazon Cognito User Pools with API Gateway, you can secure your APIs and control access based on user authentication and authorization, allowing you to build secure and scalable web and mobile applications.
Comment: Option D. Configure an Amazon Cognito user pool authorizer in API Gateway to allow Amazon Cognito to validate each request.
Comment: A is possible if the authorisation logic makes sense and does not require operational overhead. B is too much overhead for each new user. C is lol D Company already has Cognito for it's users so just integrate it with the API gateway This question and options are poorly worded an A could be a reasonable choice if more information is provided. Just keep that in mind for the exam!
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
Comment: The description of this question is really bad. Company is using Cognito to manage users already, but still verifying user info from dynamodb, very wired situation. But just select Cognito when you see Api gateway + cognito + authentication + least efforts
Comment: use Amazon Cognito to authorize user requests.
Comment: D. Configure an Amazon Cognito user pool authorizer in API Gateway to allow Amazon Cognito to validate each request
Comment: Option D is the best solution with the least operational overhead: Configure an Amazon Cognito user pool authorizer in API Gateway to allow Amazon Cognito to validate each request. The key reasons are: º Cognito user pool authorizers allow seamless integration between Cognito and API Gateway for access control. º API Gateway handles validating the access tokens from Cognito automatically without any custom code. º This is a fully managed solution with minimal ops overhead.
Comment: By configuring an Amazon Cognito user pool authorizer in API Gateway, you can leverage the built-in functionality of Amazon Cognito to authenticate and authorize users. This eliminates the need for custom development or managing access keys. Amazon Cognito handles user authentication, securely manages user identities, and provides seamless integration with API Gateway for controlling access to the REST API. A. Configuring an AWS Lambda function as an authorizer in API Gateway would require custom implementation and management of the authorization logic. B. Creating and assigning an API key for each user would require additional management and validation logic in an AWS Lambda function. C. Sending the user's email address in the header and validating it with an AWS Lambda function would also require custom implementation and management of the authorization logic. Option D, using an Amazon Cognito user pool authorizer, provides a streamlined and managed solution for controlling access to the REST API with minimal operational overhead.
Comment: solution will meet these requirements with the LEAST operational overhead is option D.
Comment: LEAST operational overhead = Serverless = Cognito user pool
Comment: D is correct.
Comment: Answer : D
Comment: D is correct
Comment: There is a difference between "Grant Access" (Authentication done by Cognito user pool), and "Control Access" to APIs (Authorization using IAM policy, custom Authorizer, Federated Identity Pool). The question very specifically asks about *Control access to REST APIs* which is a clear case of Authorization and not Authentication. So custom Authorizer using Lambda in API Gateway is the solution. Pls refer to this blog: https://aws.amazon.com/blogs/security/building-fine-grained-authorization-using-amazon-cognito-api-gateway-and-iam/
Comment: Option D: there is nothing called Cognito user pool authorizer. We only have custom Authorizer function through Lambda.
Comment: Oh yes there is :)
Comment: Control access to a REST API using Amazon Cognito user pools as authorizer https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
Comment: This answer looks to be entirely wrong This article explains how to do what you claim cannot be done: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html It starts "As an alternative to using IAM roles and policies or Lambda authorizers (formerly known as custom authorizers), you can use an Amazon Cognito user pool to control who can access your API in Amazon API Gateway." This suggests that Amazon Cognito user pools CAN be used for Authorization, which you say above cannot be done. Further, it explains how to do this... "To use an Amazon Cognito user pool with your API, you must first create an authorizer of the COGNITO_USER_POOLS type and then configure an API method to use that authorizer" So whilst A is a valid approach, it looks like D achieves the same with "the LEAST operational overhead".
Comment: Marketing communications = Amazon Pinpoint
Comment: By using Pinpoint, the company can effectively send SMS messages to its mobile app users. Additionally, Pinpoint allows the configuration of journeys, which enable the tracking and management of user interactions. The events generated during the journey, including user responses to SMS, can be captured and sent to an Kinesis data stream. This data stream can then be used for analysis and archiving purposes. A. Creating an Amazon Connect contact flow is primarily focused on customer support and engagement, and it lacks the capability to store and process SMS responses for analysis. C. Using SQS is a message queuing service and is not specifically designed for handling SMS responses or capturing them for analysis. D. Creating an SNS FIFO topic and subscribing a Kinesis data stream is not the most appropriate solution for capturing and storing SMS responses, as SNS is primarily used for message publishing and distribution. In summary, option B is the best choice as it leverages Pinpoint to send SMS messages and captures user responses for analysis and archiving using an Kinesis data stream.
Comment: https://docs.aws.amazon.com/connect/latest/adminguide/setup-sms-messaging.html
Comment: Why not A. Amazon connect has this option.
Comment: https://docs.aws.amazon.com/pinpoint/latest/userguide/welcome.html Amazon Pinpoint is the easiest solution. Amazon Connect is Contact Centre as a Service so this option is not relevant to the requirement. SQS and SNS options are overengineered or under engineered for the requirements so natural choice is "B"
Comment: base function of AWS Pinpoint
Comment: B. AWS Pinpoint is for Marketing communications.
Comment: Option B is correct answer: link: https://aws.amazon.com/pinpoint/, and video under the link.
Comment: Two-Way Messaging Receive SMS messages from your customers and reply back to them in a chat-like interactive experience. With Amazon Pinpoint, you can create automatic responses when customers send you messages that contain certain keywords.
Comment: Based on my research Kinesis stream is real time data ingestion, and also stores only event data and not the actual people responses, furthermore there is no requirement to have real time data streaming. That is probably why I am hesitating agree here with everyone on B and rather choose A.
Comment: "A Kinesis data stream stores records for 24 hours by default, up to 365 days (8,760 hours)." https://aws.amazon.com/de/blogs/big-data/retaining-data-streams-up-to-one-year-with-amazon-kinesis-data-streams/#:~:text=A%20Kinesis%20data%20stream%20stores,parallel%20and%20at%20low%2Dlatency.
Comment: The answer is B. AWS Pinpoint is for Marketing communications. AWS Connect is for Contact center.
Comment: According to the following link I would choose Option A. https://docs.aws.amazon.com/connect/latest/adminguide/web-and-mobile-chat.html
Comment: no no, there is no SMS, note the question stated all activities through SMS, also Amazon connect flow most likely working on web application UI, but if you see question clearly, this is receiving and sending SMS not through application UI (Web/Mobile App). So for those reason we choose B
Comment: Amazon Pinpoint is a flexible, scalable and fully managed push notification and SMS service for mobile apps.
Comment: It's B, see following link https://docs.aws.amazon.com/pinpoint/latest/developerguide/event-streams.html
Comment: https://aws.amazon.com/pinpoint/product-details/sms/ Two-Way Messaging: Receive SMS messages from your customers and reply back to them in a chat-like interactive experience. With Amazon Pinpoint, you can create automatic responses when customers send you messages that contain certain keywords. You can even use Amazon Lex to create conversational bots. A majority of mobile phone users read incoming SMS messages almost immediately after receiving them. If you need to be able to provide your customers with urgent or important information, SMS messaging may be the right solution for you. You can use Amazon Pinpoint to create targeted groups of customers, and then send them campaign-based messages. You can also use Amazon Pinpoint to send direct messages, such as appointment confirmations, order updates, and one-time passwords.
Comment: D: Amazon Simple Notification Service (SNS) is a fully managed messaging service that enables you to send and receive SMS messages in a cost-effective and highly scalable way. By creating an SNS FIFO topic, you can ensure that the SMS messages are delivered to your users in the order they were sent and that the SMS responses are processed and stored in the same order. You can also configure your SNS FIFO topic to publish SMS responses to an Amazon Kinesis data stream, which will allow you to store and analyze the responses for a year. Amazon Pinpoint ?¿?¿? NO! is not correct solution because while Amazon Pinpoint allows you to send SMS and Email campaigns, as well as handle push notifications to a user base, it doesn't provide SMS sending feature by itself. Furthermore, it's a service mainly focused on sending and tracking marketing campaigns, not for managing two-way SMS communication and the reception of reply.
Comment: What do think about https://docs.aws.amazon.com/pinpoint/latest/userguide/channels-sms-two-way.html?
Comment: To send SMS messages and store the responses for a year for analysis, the company can use Amazon Pinpoint. Amazon Pinpoint is a fully-managed service that allows you to send targeted and personalized SMS messages to your users and track the results. To meet the requirements of the company, a solutions architect can build an Amazon Pinpoint journey and configure Amazon Pinpoint to send events to an Amazon Kinesis data stream for analysis and archiving. The Kinesis data stream can be configured to store the data for a year, allowing the company to analyze the responses over time. So, Option B is the correct answer. Option B. Build an Amazon Pinpoint journey. Configure Amazon Pinpoint to send events to an Amazon Kinesis data stream for analysis and archiving.
Comment: KEYWORD: LEAST operational overhead To encrypt the data when it is stored in the S3 bucket and automatically rotate the encryption key every year with the least operational overhead, the company can use server-side encryption with Amazon S3-managed encryption keys (SSE-S3). SSE-S3 uses keys that are managed by Amazon S3, and the built-in key rotation behavior of SSE-S3 encryption keys automatically rotates the keys every year. To meet the requirements of the company, the solutions architect can move the data to the S3 bucket and enable server-side encryption with SSE-S3. This solution requires no additional configuration or maintenance and has the least operational overhead. Hence, the correct answer is; Option A. Move the data to the S3 bucket. Use server-side encryption with Amazon S3-managed encryption keys (SSE-S3). Use the built-in key rotation behavior of SSE-S3 encryption keys.
Comment: The good answer was B before may 2022, because the rotation schedule for AWS managed keys was 3 years (SSE-S3 is based on it)... From may 2022 the schedule rotation is 1 year, then A is now the best answer because there is NO operational task to do: S3 is by default encrypted at rest with SSE-S3 (rotation every year)... So it depends if the question has been updated since 2022
Comment: Option B involves using a customer-managed AWS KMS key and enabling automatic key rotation, but this requires the company to manage the KMS key and monitor the key rotation process. Option C involves using a customer-managed AWS KMS key, but this requires the company to manually rotate the key every year, which introduces additional operational overhead. Option D involves encrypting the data with customer key material and creating a KMS key without key material, but this requires the company to manage the customer key material and import it into the KMS key, which introduces additional operational overhead.
Comment: But... For A there is no reference to how often these keys are rotated, and to rotate to a new key, you need to upload it, which is operational overhead. So not only does it not necessarily meet the 'rotate keys every year' requirement, but every year it requires operational overhead. More importantly, the question states move the objects first, and then configure encryption, but ..."There is no change to the encryption of the objects that existed in the bucket before default encryption was enabled." from https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html So A is clearly wrong. For B, whilst you have to set up KMS once, you then don't have to anything else, which i would say is LEAST operational overhead.
Comment: God bless you, man! The most articulated answers, easy to understand. Good job!
Comment: But wrong :)
Comment: Reviewed it the second time. Some of them are wrong, indeed.
Comment: The order of these events is being ignored here in my opinion. The encryption checkbox needs to be checked before data is moved into the S3 bucket or it will not be encrypted otherwise, you'll have to encrypt manually and reload into S3 bucket. If the box was checked before moving data into S3 then you are good to go !
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html
Comment: SSE DOES not rotate encryption keys, it changes master key used to lock encryption keys which creates new ciphered key and stores it.
Comment: Ignoring the new changes that the default encryption is already enabled. I agree that the encryption should be configured before moving the data into the bucket. Otherwise, the existing objects will remain unencrypted. Correct Answer is B. Additionally, where is the reference that SSE-S3 will rotate keys every year (which is the question's requirement).
Comment: SSE-S3 rotates the keys when AWS wants it, not "every year" like required here.
Comment: No, I stand corrected. All AWS managed keys are automatically rotated every year. You cannot change this rotation schedule.
Comment: I want to find a source for this yearly rotation because SSE-S3 just rotates periodically and doesn't say it follows the same policy as other managed key. I think you may be right but just need a doc link
Comment: https://repost.aws/questions/QUES_1VN01TU-eRSO3LXergA/s3-managed-key-sse-s3-rotation-period
Comment: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys
Comment: SSE-S3 - is free and uses AWS owned CMKs (CMK = Customer Master Key). The encryption key is owned and managed by AWS, and is shared among many accounts. Its rotation is automatic with time that varies as shown in the table here. The time is not explicitly defined. SSE-KMS - has two flavors: AWS managed CMK. This is free CMK generated only for your account. You can only view it policies and audit usage, but not manage it. Rotation is automatic - once per 1095 days (3 years), Customer managed CMK. This uses your own key that you create and can manage. Rotation is not enabled by default. But if you enable it, it will be automatically rotated every 1 year. This variant can also use an imported key material by you. If you create such key with an imported material, there is no automated rotation. Only manual rotation. SSE-C - customer provided key. The encryption key is fully managed by you outside of AWS. AWS will not rotate it.
Comment: AWS managed CMK rotates every 365 days (not 1095 days). Reference: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt
Comment: SSE-S3 is powerful for data encryption at rest guys. Each single object is encrypted with a different key. SSE-S3 automatically rotates all keys. However, SSE-S3 does not log any information concerning key encryption or rotation.
Comment: Rotation on a yearly basis.
Comment: As far as I know, SSE-S3 encryption uses keys which we can't view, nor do we know the rotation period of them. SSE-S3 and AWS-Managed KMS Keys are not the same: AWS Managed KMS Keys are rotated every 365 days AWS Customer-Managed Keys have optional rotation SSE-S3 Encryption is not either of them, thus A should be eliminated. Since we do not have an option here to use an AWS-managed KMS key, the only valid option is to use a customer-managed key and enable key rotation.
Comment: All options except A suggesting cusomer key, why customer key would be needed here.
Comment: B for sure
Comment: AWS can change rotation period anytime but Customer says 'must be automatically rotated' hence answer should be B in this case.
Comment: Interestingly the answer for this used to be B, and now its A. After May 2022 AWS changed the rotation schedule for SSE-S3. See documentation here: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-aws-managed-keys . AWS managed keys AWS KMS automatically rotates AWS managed keys every year (approximately 365 days). You cannot enable or disable key rotation for AWS managed keys. In May 2022, AWS KMS changed the rotation schedule for AWS managed keys from every three years (approximately 1,095 days) to every year (approximately 365 days). New AWS managed keys are automatically rotated one year after they are created, and approximately every year thereafter. Existing AWS managed keys are automatically rotated one year after their most recent rotation, and every year thereafter. ---- If this comes up in the exam, remember ! you can use SSE-S3 for yearly rotation now.
Comment: SSE-KMS - Customer managed keys - Automatic rotation - Guarantees yearly key rotation (unlike SSE-S3 where you do not have control on key rotation) and also meets the least operational overhead.
Comment: Option A: Utilizes server-side encryption with Amazon S3 managed encryption keys (SSE-S3), which is the simplest and most straightforward way to encrypt data stored in Amazon S3. SSE-S3 automatically handles key rotation, eliminating the need for manual key rotation. This solution provides encryption for the data in the S3 bucket without requiring any additional setup or management. Option B: Involves setting up a customer managed KMS key, enabling automatic key rotation, and then setting the S3 bucket's default encryption behavior to use the customer managed KMS key. While this option also provides encryption and automatic key rotation, it involves more setup and management compared to SSE-S3.
Comment: It's A. Because it's said that they need with LEAST operation overhead and S3 Managed Keys can rotate automatically every year without needing the user intervention. For the Customer Managed Keys, you need to do some configuration for that.
Comment: Both A and B are viable answers but A with SSE-S3 is least operational overhead. B will require customer to manage the key. ***HOWEVER*** note that SSE-S£ managed keys are rotated periodically so there is no user control on limiting the rotation to "once a year". For exam, probably read the question with full context and hope there is more detail in the actual exam!
Comment: Please see JayBee response below. Make sense.
Comment: Now "all AWS managed keys are automatically rotated every year. You cannot change this rotation schedule". However, if you insist that option A also specifies the order of steps then it would be wrong, you'd need to enable encryption BEFORE moving the data to the bucket. But per my understanding of English, the order is not specified, it's just a combination of things you do. Otherwise B would be the correct answer, but it has more operational overhead than A, at least now. Probably the question is old.
Comment: nowhere in this documentation states how often the keys are rotated, and only the key that encrypts the S3 encryption key actually gets to rotate. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html
Comment: I'm voting B Each object in s3 using SSE-S3 uses separate key, this key is encrypted using another master key that is regularly rotated but AWS doesn't share how often it happens. With SSE-KMS you have option to tick: "Automatically rotate this KMS key every year.".
Comment: In 2023 the answer would be A. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html states that S3 automatically uses SSE, and rotates the keys "regularly" which as far as I've understood is yearly
Comment: but based on this reference: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys it mentions varies, so i would stick with B
Comment: Option D. Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue. To resolve the issue of longer delivery times for meeting invitations, the solutions architect can recommend adding an Auto Scaling group for the application that sends meeting invitations and configuring the Auto Scaling group to scale based on the depth of the SQS queue. This will allow the application to scale up as the number of appointment requests increases, improving the performance and delivery times of the meeting invitations.
Comment: By adding an ASG for the application that sends meeting invitations and configuring it to scale based on the depth of the SQS, the system can automatically adjust its capacity based on the number of pending messages in the queue. This ensures that the application can handle increased message load and process the meeting invitations more efficiently, reducing the delay experienced by customers. A. Adding a DynamoDB Accelerator (DAX) cluster in front of the DynamoDB database would improve read performance for DynamoDB, but it does not directly address the issue of delayed meeting invitations. B. Adding an API Gateway API in front of the web application that accepts the appointment requests may help with request handling and management, but it does not directly address the issue of delayed meeting invitations. C. Adding an CloudFront distribution with the web application as the origin would improve content delivery and caching, but it does not directly address the issue of delayed meeting invitations.
Comment: First question with consistent answer :)
Comment: Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue.
Comment: Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue.
Comment: Option D is the right Answer,
Comment: Agreed
Comment: ANswer d
Comment: D meets the requirements
Comment: Answer : D
Comment: Answer : C keyword "manage-fine-grained" https://aws.amazon.com/blogs/big-data/manage-fine-grained-access-control-using-aws-lake-formation/
Comment: You can manage fine grained using redshift as well - https://aws.amazon.com/blogs/big-data/achieve-fine-grained-data-security-with-row-level-access-control-in-amazon-redshift/ But, I believe the keyword to look for is "minimize operational overhead", which lakeformation does without duplicating much of the data. Redshift is operational overhead and duplication of data. not sure why the answer is D. i vote C as well.
Comment: yeah, most of examtopics answers are wrong
Comment: Answer is C
Comment: Keyword: "manage fine-grained permissions for data" Data Lake Using Lake Formation: manage fine-grained permissions for the data with ease. Fine grained permissions for data = Lake Formation Answer: C
Comment: C represents the easiest way to ingest data from S3 and control accesses.
Comment: a fine grained permissons is one of the conditions to acomplishes with the requirement. With the use of AWS Glue you can get acomplishes with this requirement. My answer is: C
Comment: With Lake formation you can scale permissions more easily with fine-grained security capabilities, including row- and cell-level permissions and tag-based access control.
Comment: Lake Formation enables the creation of a secure and scalable data lake on AWS, allowing centralized access controls for both S3 and RDS data. By using Lake Formation, the company can manage permissions effectively and integrate RDS data through the AWS Glue JDBC connection. Registering the S3 in Lake Formation ensures unified access control. This solution reduces operational overhead while providing fine-grained permissions management.
Comment: Lake Formation enables the creation of a secure and scalable data lake on AWS, allowing centralized access controls for both S3 and RDS data. By using Lake Formation, the company can manage permissions effectively and integrate RDS data through the AWS Glue JDBC connection. Registering the S3 in Lake Formation ensures unified access control. This solution reduces operational overhead while providing fine-grained permissions management. A. Directly writing purchase data to Amazon RDS with RDS access controls lacks comprehensive permissions management for both S3 and RDS data. B. Periodically copying data from RDS to S3 using Lambda and using AWS Glue and Athena for querying does not offer fine-grained permissions management and introduces data synchronization complexities. D. Creating an Redshift cluster and copying data from S3 and RDS to Redshift adds complexity and operational overhead without the flexibility of Lake Formation's permissions management capabilities.
Comment: Answer is C AWS Lake Formation provides a comprehensive solution for building and managing a data lake. It simplifies data ingestion, organization, and access control. By creating a data lake using AWS Lake Formation, you can centralize and govern access to your data across multiple sources.
Comment: Option C is right answer: https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html
Comment: Lake Formation helps you manage fine-grained access for internal and external customers from a centralized location and in a scalable way.
Comment: https://docs.aws.amazon.com/lake-formation/latest/dg/access-control-overview.html
Comment: To me, the give-away was: "The company wants to make all the data available to various teams" - Data-Lake - All data in one place.
Comment: The correct answer is D. The company uses all the data from various teams so that the teams can do their analysis. Therefore, it is the best way to separately configure redshift for data warehousing and for all employees to connect to the redshift DB and perform analysis tasks without burdening the operating DB (must minimize operational overhead).
Comment: I don't think that "periodically copy data from Amazon S3 and RDS to Redshift" minimize the operational overhead. The correct answer for me is C
Comment: Manage fine-grained access control using AWS Lake Formation https://aws.amazon.com/blogs/big-data/manage-fine-grained-access-control-using-aws-lake-formation/
Comment: Option C. Create a data lake by using AWS Lake Formation. Create an AWS Glue JDBC connection to Amazon RDS. Register the S3 bucket in Lake Formation. Use Lake Formation access controls to limit access. To make all the data available to various teams and minimize operational overhead, the company can create a data lake by using AWS Lake Formation. This will allow the company to centralize all the data in one place and use fine-grained access controls to manage access to the data. To meet the requirements of the company, the solutions architect can create a data lake by using AWS Lake Formation, create an AWS Glue JDBC connection to Amazon RDS, and register the S3 bucket in Lake Formation. The solutions architect can then use Lake Formation access controls to limit access to the data. This solution will provide the ability to manage fine-grained permissions for the data and minimize operational overhead.
Comment: ..................
Comment: a combination of the following 2 URLs I believe it is C https://aws.amazon.com/lake-formation/ https://aws.amazon.com/blogs/big-data/manage-fine-grained-access-control-using-aws-lake-formation/
Comment: The question here is whether the solution architect can change the requirement. The requirement says very clear about SFTP which cannot be addressed by option C. But the question also gives very clear hint about OAI which cannot be addressed by option D. Option D also doesn't mention anything about CloudFront which is part of the requirement of the question. So, if the requirement cannot be changed, D is the answer; if the requirement can be changed, C is the answer. But if the requirement can be changed, what's the limitation? That will be a Chaos. I'm voting C, and curse the question designer.
Comment: "The solutions architect must design the most cost-effective and resilient architecture for website hosting to serve as the CloudFront origin." The solution architect is looking for a solution that can fit with CloudFront as origin! So it doesn't matter that option D does not mention CF, CF is part of the solution! Having a marketing website on-premise clearly indicates having S3 as static content. AWS Transfer Family is the way to upload files via FTP to S3! So the answer is D. Why not C? User is already uploading content via FTP, option C is eliminating this option for him and forces using the CLI. The solution from C does not meet the requirements of having FTP.
Comment: Hosting the website in a private S3 provides cost-effective and highly available storage for the static website content. By configuring a bucket policy to allow access from a CloudFront OAI, the S3 can be securely accessed only through CloudFront. This ensures that the website content is served through CloudFront while keeping the S3 private. Uploading website content using the AWS CLI allows for easy and efficient content management. A. Hosting the website on an Lightsail virtual server would introduce additional management overhead and costs compared to using S3 directly for static content hosting. B. Using an AWS ASG with EC2 instances and an ALB is not necessary for serving static website content. It would add unnecessary complexity and cost. D. While using AWS Transfer for SFTP allows for SFTP uploads, it introduces additional costs and complexity compared to directly uploading content to an S3 using the AWS CLI. Additionally, hosting the website content in a public S3 may not be desirable from a security standpoint.
Comment: the option D creating a public S3 bucket could expose the website content to the public, which is a security risk. Using an OAI with a private S3 bucket (as in Option C) is more secure. AWS Transfer for SFTP adds unnecessary complexity unless SFTP specifically is required.
Comment: "The company... use Amazon CloudFront" = C is the only option that mentions CloudFront.
Comment: This is another great example of how AWS creates crappy tests. Even internal Tests for employees have so many flaws that people is always creating tickets challenging Questions poorly worded.
Comment: Another reason why A is better than C: “ OAC helps you secure your origins, such as for Amazon S3. We recommend using OAC” “ If your origin is an Amazon S3 bucket configured as a website endpoint, you must set it up with CloudFront as a custom origin. That means you can't use OAC (or OAI)” https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
Comment: you can see in this figure that transfer family framework allows for the data to be available for a broad variety of use cases including content distribution (CF) https://d1.awsstatic.com/HIW%20SFTP%20Connectors%20v3.920176622d281d0bd087518827314169b496a055.png
Comment: Two main problems with D: It's public S3 behind CloudFront which is not well-architected Infrequent site updates using SFTP so with S3 it will be cli changes. They don't need fancy transfer for this. Right?
Comment: I think the this is a big misleading " SFTP" ( doesn't usally upload) ，and it said clearly need Cloudfront and want a cheep solution. So I chose "C"
Comment: Transfering via AWS CLI is cheaper than via Transfer Family. It is not the best option, but will do the job of uploading the data to S3.
Comment: I'd go with D. In C there is no mention to S3 bucket being configured for web hosting. Simply adding the Cloudfront distribution and pointing that to the S3 won't work out of the box.
Comment: D - SFTP client to upload new documents.
Comment: D is the only one possible. C cannot be because: In Amazon CloudFront: For Restricting access to an Amazon S3 origin: If your origin is an Amazon S3 bucket configured as a website endpoint, you must set it up with CloudFront as a custom origin. That means you can't use OAC (or OAI). https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
Comment: I changed C. is better then D
Comment: D - SFTP client to upload new documents.
Comment: AWS transfer is a cost and doesn't mention using CloudFront https://aws.amazon.com/aws-transfer-family/pricing/
Comment: If you don't want to disable block public access settings for your bucket but you still want your website to be public, you can create a Amazon CloudFront distribution to serve your static website. For more information, see Use an Amazon CloudFront distribution to serve a static website in the Amazon Route 53 Developer Guide. https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteAccessPermissionsReqd.html
Comment: I at first thought D but it is in fact C because "D: Create a public Amazon S3 bucket. Configure AWS Transfer for SFTP. Configure the S3 bucket for website hosting. Upload website content by using the SFTP client." questions says that the company has decided to use Amazon Cloudfront and this answer does not reference using CF and setting S3 as the Origin "C. Create a private Amazon S3 bucket. Use an S3 bucket policy to allow access from a CloudFront origin access identity (OAI). Upload website content by using the AWS CLI." - mentions CF and the origin and the AWS CLI does infact support transfer by SFTP (which was the part I originally doubted but this link evidences that it does: https://docs.aws.amazon.com/cli/latest/reference/transfer/describe-server.html
Comment: Option C, creating a private Amazon S3 bucket and using an S3 bucket policy to allow access from a CloudFront origin access identity (OAI), would not be the most cost-effective solution. While it would allow the company to use Amazon S3 for storage, it would also require additional setup and maintenance of the OAI, which would add additional cost. Additionally, this solution would not allow the use of SFTP client for uploading content which is the current method used by the company.
Comment: The Answer is C https://medium.com/aws-poc-and-learning/how-to-access-s3-hosted-website-via-cloudfront-using-oai-origin-access-identity-720ad7c57f15
Comment: I'm team C. https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitor-ami-events.html#:~:text=For%20example%2C%20you%20can%20create%20an%20EventBridge%20rule%20that%20detects%20when%20the%20AMI%20creation%20process%20has%20completed%20and%20then%20invokes%20an%20Amazon%20SNS%20topic%20to%20send%20an%20email%20notification%20to%20you.
Comment: C is correct > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitor-ami-events.html
Comment: That link contains the exact use case and explains how C can be used. Option B requires you to send logs to S3 and use Athena, 2 additional services that are not required, so this does not meet the "LEAST operational overhead?" requirement, since these are extra services requiring management.
Comment: Why not A? API calls are already logged in Cloudtrail.
Comment: "Least operational overhead" is when the event triggers an action, not when you run a scheduled task that searches logs for the event.
Comment: C all day. Trust me
Comment: It can be done with option A but you'll have to write a lambda function. option C is least operational overhead.
Comment: Monitor AMI events using Amazon EventBridge is possible and here is the link: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitor-ami-events.html
Comment: Just took the exam today, most of the questions were from here wish I saw them all to be honest before entering the exam. Anyways, this question was at the exam, I picked option A because as the question stated it wanted two things not one thing only an aplication that CAPTURES API calls and SEND ALERTS WHENEVER Createimage API call is made, OPTION C CLEARLY STATES THAT IN THIS CASE IT WILL ONLYYY LOOK FOR CREATEIMAGE API CALL it will not capture other API calls like the lambda in option A would! Am i the only one that is thinks that or what? TBH I am not sure about anything in this question but that is why I did not pick option C during the exam.
Comment: On of the requirements is LEAST operational overhead CloudTrail sends a notification when log files are written to the Amazon S3 bucket. An active account can generate a large number of notifications. If you subscribe with email or SMS, you can receive a large volume of messages. We recommend that you subscribe using Amazon Simple Queue Service (Amazon SQS), which lets you handle notifications programmatically. For more information, see Subscribing a Queue to an Amazon SNS Topic in the Amazon Simple Queue Service Developer Guide.
Comment: Answer is c.
Comment: C is correct
Comment: AWS CloudTrail primarily focuses on auditing and recording API calls made in your AWS account. It logs all API requests made via the AWS Management Console, AWS SDKs, command line tools, and other AWS services. This includes the identity of the caller, the time of the API call, the source IP address of the caller, the request parameters, and the response elements returned by the AWS service. This information is useful for security analysis, resource change tracking, and troubleshooting.
Comment: But this is not about "auditing and recording", you don't want to create reports who created images during the last year, you want an instant alert when someone creates an image. Thus CloudWatch Events.
Comment: Cloud Watch = AWS Monitoring service for any AWS resources Cloud Trail = AWS API monitoring service with respect to application event that are hosted on AWS. Answer would be "C" https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitor-ami-events.html service
Comment: "LEAST operational overhead" Option A envolves coding a Lamba. Not good! Option C seems to be the correct.
Comment: Event bridge was built specifically to handle this kind of scenario: CreateImage API call (Event Source) -> Event bus -> Rules - > Amazon SNS (Event target)
Comment: C. Create an Amazon EventBridge (Amazon CloudWatch Events) rule for the CreateImage API call. Configure the target as an Amazon Simple Notification Service (Amazon SNS) topic to send an alert when a CreateImage API call is detected
Comment: A look like the least overhead option to capture an API call.
Comment: The company needs to design an application that captures AWS API calls and sends alerts whenever the Amazon EC2 CreateImage API operation is called within the company's account. With option C, it won't "The company needs to design an application that captures AWS API calls". it only sends the "CreateImage API " event. We need to store the AWS API calls as well.
Comment: EventBridge (formerly CloudWatch Events) is a fully managed event bus service that allows you to monitor and respond to events within your AWS environment. By creating an EventBridge rule specifically for the CreateImage API call, you can easily detect and capture this event. Configuring the target as an SNS topic allows you to send an alert whenever a CreateImage API call occurs. This solution requires minimal operational overhead as EventBridge and SNS are fully managed services. A. While using an Lambda to query CloudTrail logs and send an alert can achieve the desired outcome, it introduces additional operational overhead compared to using EventBridge and SNS directly. B. Configuring CloudTrail with an SNS notification and using Athena to query on CreateImage API calls would require more setup and maintenance compared to using EventBridge and SNS. D. Configuring an SQS FIFO queue as a target for CloudTrail logs and using a function to send an alert to an SNS topic adds unnecessary complexity to the solution and increases operational overhead. Using EventBridge and SNS directly is a simpler and more efficient approach.
Comment: A does not meet the "without impacting existing users" requirement B does not help with writing (DAX caches reads) C does not help with writing (index could increase read performance only) D decouples writing from front-end, which is acceptable because it is "an asynchronous API" anyway
Comment: The key here is "Losing user requests" sqs messages will stay in the queue until it has been processed
Comment: D bro. Believe
Comment: This solution can handle bursts of incoming requests more effectively and reduce the chances of losing requests due to DynamoDB capacity limitations. The Lambda can be configured to retrieve messages from the SQS and write them to DynamoDB at a controlled rate, allowing DynamoDB to handle the requests within its provisioned capacity. This approach provides resilience to spikes in traffic and ensures that requests are not lost during periods of high demand.
Comment: This solution can handle bursts of incoming requests more effectively and reduce the chances of losing requests due to DynamoDB capacity limitations. The Lambda can be configured to retrieve messages from the SQS and write them to DynamoDB at a controlled rate, allowing DynamoDB to handle the requests within its provisioned capacity. This approach provides resilience to spikes in traffic and ensures that requests are not lost during periods of high demand. A. It limits can help control the request rate, but it may lead to an increase in errors and affect the user experience. Throttling alone may not be sufficient to address the availability issues and prevent the loss of requests. B. It can improve read performance but does not directly address the availability issues and loss of requests. It focuses on optimizing read operations rather than buffering writes. C. It may help with querying the user requests efficiently, but it does not directly solve the availability issues or prevent the loss of requests. It is more focused on data retrieval rather than buffering writes.
Comment: DAX is for reads
Comment: DAX is not ideal for the following types of applications: Applications that require strongly consistent reads (or that cannot tolerate eventually consistent reads). Applications that do not require microsecond response times for reads, or that do not need to offload repeated read activity from underlying tables. Applications that are write-intensive, or that do not perform much read activity. Applications that are already using a different caching solution with DynamoDB, and are using their own client-side logic for working with that caching solution.
Comment: D because SQS is the cheapest way. First 1,000,000 requests are free each month. Question states: "The company provisioned as much DynamoDB throughput as its budget allows"
Comment: D is more likely to fix this problem as SQS queue has the ability to wait (buffer) for consumer to notify that the request or message has been processed.
Comment: To address the issue of lost user requests and improve the availability of the API, the solutions architect should use the Amazon Simple Queue Service (Amazon SQS) queue and Lambda to buffer writes to DynamoDB. Option D (correct answer) By using an SQS queue and Lambda, the solutions architect can decouple the API front end from the processing microservices and improve the overall scalability and availability of the system. The SQS queue acts as a buffer, allowing the API front end to continue accepting user requests even if the processing microservices are experiencing high workloads or are temporarily unavailable. The Lambda function can then retrieve requests from the SQS queue and write them to DynamoDB, ensuring that all user requests are stored and processed. This approach allows the company to scale the processing microservices independently from the API front end, ensuring that the API remains available to users even during periods of high demand.
Comment: I would go to B : https://aws.amazon.com/es/blogs/database/amazon-dynamodb-accelerator-dax-a-read-throughwrite-through-cache-for-dynamodb/
Comment: That's wrong. The document you mentioned explained it very clearly: "Whereas both read-through and write-through caches address read-heavy workloads, a write-back (or write-behind) cache is designed to address write-heavy workloads. Note that DAX is not a write-back cache currently"
Comment: D is correct answer
Comment: D. Use the Amazon Simple Queue Service (Amazon SQS) queue and Lambda to buffer writes to DynamoDB.
Comment: Option D is right answer
Comment: Why not B? DAX. "When you're developing against DAX, instead of pointing your application at the DynamoDB endpoint, you point it at the DAX endpoint, and DAX handles the rest. As a read-through/write-through cache, DAX seamlessly intercepts the API calls that an application normally makes to DynamoDB so that both read and write activity are reflected in the DAX cache." https://aws.amazon.com/es/blogs/database/amazon-dynamodb-accelerator-dax-a-read-throughwrite-through-cache-for-dynamodb/
Comment: B is wrong because of this: "Whereas both read-through and write-through caches address read-heavy workloads, a write-back (or write-behind) cache is designed to address write-heavy workloads. Note that DAX is not a write-back cache currently"
Comment: It is not DAX because of the company's budget restriction associated with the DynamoDB. This is a requirement in the question. DynamoDB charges for DAX capacity by the hour and your DAX instances run with no long-term commitments. Please refer to: https://aws.amazon.com/dynamodb/pricing/provisioned/#.E2.80.A2_DynamoDB_Accelerator_.28DAX.29
Comment: yeah I though the answer is also DAX.
Comment: Using SQS should be the answer.
Comment: Why not DAX? Could somebody explain?
Comment: DAX helps in reducing the read loads from DynamoDB, here we need a solution to handle write requests, which is well handled by SQS and Lamda to buffer writes on DynamoDB.
Comment: key noted issue is "losing user requests" which is resolved with SQS
Comment: Using DynamoDB Accelerator (DAX) and Lambda to buffer writes to DynamoDB, may improve the write performance of the system, but it does not provide the same level of scalability and availability as using an SQS queue and Lambda. Hence, Option B is incorrect.
Comment: Answer d
Comment: I think answer should be A and not B. as we cannot "Attach a security groups to a gateway endpoint."
Comment: It's possible: https://aws.amazon.com/premiumsupport/knowledge-center/connect-s3-vpc-endpoint/
Comment: No, it's not
Comment: Create a security group that allows the resources in your VPC to communicate with the endpoint network interfaces for the VPC endpoint. To ensure that tools such as the AWS CLI can make requests over HTTPS from resources in the VPC to the AWS service, the security group must allow inbound HTTPS traffic. For Security groups, select the security groups to associate with the endpoint network interfaces for the VPC endpoint. By default, we associate the default security group for the VPC.
Comment: this is valid for interface endpoint, not for gateway endpoint, which option B mentioned
Comment: Gateway endpoint must be used as a target in a route table does not use security groups.
Comment: Go to console and test it yourself! With Interface Endpoint you can add security groups.
Comment: The correct solution to meet the requirements is Option B. A gateway VPC endpoint for Amazon S3 should be created in the Availability Zone where the EC2 instance is located. This will allow the EC2 instance to access the S3 bucket directly, without routing through the public internet. The endpoint should also be configured with appropriate security groups to allow access to the S3 bucket. Additionally, a resource policy should be attached to the S3 bucket to only allow the EC2 instance's IAM role for access.
Comment: Option A is incorrect because an interface VPC endpoint for Amazon S3 would not provide a direct connection between the EC2 instance and the S3 bucket. Option C is incorrect because using the nslookup tool to obtain the private IP address of the S3 bucket's service API endpoint would not provide a secure connection between the EC2 instance and the S3 bucket. Option D is incorrect because using the ip-ranges.json file to obtain the private IP address of the S3 bucket's service API endpoint is not a secure method to connect the EC2 instance to the S3 bucket.
Comment: There are two types VPC Endpoint: Gateway endpoint Interface endpoint A Gateway endpoint: 1) Helps you to securely connect to Amazon S3 and DynamoDB 2) Endpoint serves as a target in your route table for traffic 3) Provide access to endpoint (endpoint, identity and resource policies) An Interface endpoint: 1) Help you to securely connect to AWS services EXCEPT FOR Amazon S3 and DynamoDB 2) Powered by PrivateLink (keeps network traffic within AWS network) 3) Needs a elastic network interface (ENI) (entry point for traffic)
Comment: interface endpoint exists for S3 as well
Comment: An interface VPC endpoint does provide a direct connection between the EC2 instance and the S3 bucket. It enables private communication between instances in your VPC and resources in other services without requiring an internet gateway, a NAT device, or a VPN connection. Option A , which recommends creating an interface VPC endpoint for Amazon S3 in the subnet where the EC2 instance is located and attaching a resource policy to the S3 bucket to only allow the EC2 instance's IAM role for access, is the correct solution for the given scenario. It meets the requirement to ensure that no API calls and no data are routed through public internet routes and that only the EC2 instance can have access to upload data to the S3 bucket.
Comment: In support, see https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3
Comment: Gateway endpoint for S3 Use Amazon S3 public IP addresses, while interface endpoint use private IP addresses from your VPC to access Amazon S3. As mentioned, no traffic is allowed through the public route, so ANS is A
Comment: I vote for A, because there is no option to attach security group for gateway vpc endpoint. Apart from that in most cases gateway endpoint is preferable for S3, but this little detail about the security group changes my answer for A. Gateway endpoints uses routing tables instead security groups.
Comment: Interface VPC endpoints are more suited for services that require private connectivity via a network interface. For S3, a Gateway VPC Endpoint is more appropriate and cost-effective since it integrates at the route table level without requiring additional cost per endpoint.
Comment: its A, private equals interfsce. https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3
Comment: Answer Should be B. You can attached security group with VPC endpoint. This is not the point. For S3 you need to create gateway VPC endpoint not interface VPC endpoint.
Comment: Gateway endpoints do not enable AWS PrivateLink. So the answer is A.
Comment: It's definitely A, B is wrong because we configure route table for Gateway VPC Endpoint, not security group or subnet
Comment: Gateway endpoint would be sufficient here which is specifically for S3 and dynamo DB and don't incurr any charges. Interface VPC endpoint might be usefull if a scneario with cross region or on-premises connectivity within private VPC https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html
Comment: The wording in B says create a gateway VPC endpoint in the AZ, surely it should say in the VPC...... L
Comment: A for sure
Comment: DynamoDB & S3 uses Gateway VPC endpoint (not interface)
Comment: You associate a gateway endpoint with a VPC and its subnets (so the prefix list can be added to the appropriate routing tables). You cannot specify an AZ or associate an SG when creating a gateway endpoint.
Comment: It must be Interface VPC endpoint. As the Gateway VPC endpoint requires a S3 pubilc IP address to work: https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html If the bucket has a public IP address, it means the bucket is publicy accessible, which is not the case here.
Comment: we cannot "Attach a security groups to a gateway endpoint."
Comment: im almost certain that the answers in this question are written slightly wrong. there is no reason (based on the question), for you to select A. Only EC2 needs access to S3, 99% of the time you'd use a gateway endpoint. Reasons you might use an interface endpoint are: - requirement of on-premise access to S3 - requirement of access from another VPC in another region using peering or transit gateway - requirement of using specific endpoint S3 DNS names - use of private IPs from your VPC to access S3 based on the above, i believe the answer to be B, its just written incorrectly with the addition of the security groups part.
Comment: The correct answer is A. Use Amazon ElastiCache to manage and store session data. In order to support distributed session data management in this scenario, it is necessary to use a distributed data store such as Amazon ElastiCache. This will allow the session data to be stored and accessed by multiple EC2 instances across multiple Availability Zones, which is necessary for a scalable and highly available architecture. Option B, using session affinity (sticky sessions) of the ALB, would not be sufficient because this would only allow the session data to be stored on a single EC2 instance, which would not be able to scale across multiple Availability Zones. Options C and D, using Session Manager and the GetSessionToken API operation in AWS STS, are not related to session data management and would not be appropriate solutions for this scenario.
Comment: A is the correct answer because it allows to manage distributed sessions
Comment: A is in scope of question as company is willing to make code changes. B would have been correct if no code changes were allowed and scaling could be compromised. C is wrong technology (cloud management) D is also wrong technology (AWS IAM or account management).
Comment: A is correct B is not correct as session affinity allow web user stick to a EC2 instance for a period time, that EC2 could go down then the session data will lost, so doesn't fit this use case C is wrong as Session Manager is for admins users to manage EC2 CLI access, it's not for web end users D is wrong as GetSessionToken API is for use case such as you need to grant user access to a S3 bucket with customized code
Comment: Yap agree with go you guys, this is one of the use cases for Amazon ElastiCache. It was designed to store ephemeral session data to quickly personalize gaming, e-commerce, social media, and online applications with microsecond response times. https://aws.amazon.com/elasticache/#:~:text=Store-,ephemeral,-session%20data%20to
Comment: https://aws.amazon.com/elasticache/#:~:text=Store%20ephemeral%20session%20data%20to%20quickly%20personalize%20gaming%2C%20e%2Dcommerce%2C%20social%20media%2C%20and%20online%20applications%20with%20microsecond%20response%20times.
Comment: The correct answer is A. Use Amazon ElastiCache to manage and store session data.
Comment: ElastiCache is a managed in-memory data store service that is well-suited for managing session data in a distributed architecture. It provides high-performance, scalable, and durable storage for session data, allowing multiple EC2 instances to access and share session data seamlessly. By using ElastiCache, the application can offload the session management workload from the EC2 instances and leverage the distributed caching capabilities of ElastiCache for improved scalability and performance. Option B, using session affinity (sticky sessions) of the ALB, is not the best choice for distributed session data management because it ties each session to a specific EC2 instance. As the instances scale up and down frequently, it can lead to uneven load distribution and may not provide optimal scalability. Options C and D are not applicable for managing session data. AWS Systems Manager's Session Manager is primarily used for secure remote shell access to EC2 instances, and the AWS STS GetSessionToken API operation is used for temporary security credentials and not session data management.
Comment: ElastiCache is a managed in-memory data store service that is well-suited for managing session data in a distributed architecture. It provides high-performance, scalable, and durable storage for session data, allowing multiple EC2 instances to access and share session data seamlessly. By using ElastiCache, the application can offload the session management workload from the EC2 instances and leverage the distributed caching capabilities of ElastiCache for improved scalability and performance. Option B, using session affinity (sticky sessions) of the ALB, is not the best choice for distributed session data management because it ties each session to a specific EC2 instance. As the instances scale up and down frequently, it can lead to uneven load distribution and may not provide optimal scalability. Options C and D are not applicable for managing session data. AWS Systems Manager's Session Manager is primarily used for secure remote shell access to EC2 instances, and the AWS STS GetSessionToken API operation is used for temporary security credentials and not session data management.
Comment: A. Use Amazon ElastiCache to manage and store session data. - Correct. - Session data is managed at the application-layer, and a distributed cache should be used B. Use session affinity (sticky sessions) of the ALB to manage session data. - Wrong. This tightly couples the individual EC2 instances to the session data, and requires additional logic in the ALB. When scale-in happens, the session data stored on individual EC2 instances is destroyed
Comment: correct answer is A as instance are getting up and down.
Comment: 야 근데 210문제는 어딧냐 ..?
Comment: https://www.examtopics.com/discussions/amazon/view/94992-exam-aws-certified-solutions-architect-associate-saa-c03/ 여기 임마
Comment: Amazon ElastiCache to manage and store session data.
Comment: https://www.examtopics.com/discussions/amazon/view/46412-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A Amazon ElastiCache to manage and store session data. This solution will allow the application to automatically scale across multiple Availability Zones without losing session data, as the session data will be stored in a cache that is accessible from any EC2 instance. Additionally, using Amazon ElastiCache will enable the company to easily manage and scale the cache as needed, without requiring any changes to the application code. Option C is not correct because,Session Manager from AWS Systems Manager will not provide the necessary support for distributed session data management. Session Manager is a tool for managing and tracking sessions on EC2 instances, but it does not provide a mechanism for storing and managing session data in a distributed environment.
Comment: better justification found here... https://www.examtopics.com/discussions/amazon/view/46412-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: why not C?
Comment: ALB sticky session can keep request accessing to the same backend application. But it says "distributed session management" and company "will to change code", so I think A is better
Comment: When the backlog per instance reaches the target value, a scale-out event will happen. Because the backlog per instance is already 150 messages (1500 messages / 10 instances), your group scales out, and it scales out by five instances to maintain proportion to the target value. Backlog per instance: To calculate your backlog per instance, start with the ApproximateNumberOfMessages queue attribute to determine the length of the SQS queue (number of messages available for retrieval from the queue). Divide that number by the fleet's running capacity, which for an Auto Scaling group is the number of instances in the InService state, to get the backlog per instance. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
Comment: C is incorrect as scaling based on the number of "notifications" doesn't make logical sense. This means that both the order collection and fulfilment instances would scale in parallel, but they have clearly said that the collection is processing quickly while the fulfilment is struggling. Therefore, we should scale the pool when there is a backlog building in a respective queue - not just based on the number of incoming requests.
Comment: both have their own queue. Instance processing order will be scale up based on the queue length that collect messages that collected by other queue.
Comment: not C as the questions state that only one system is struggling, so C doesnt really solve the problem. D does.
Comment: Decoupling with Amazon SQS: By using Amazon SQS queues for order collection and order fulfillment, the system can decouple the components, ensuring that orders are not lost, even during scaling events. Orders are queued up and processed in a reliable and scalable manner. Scalability Based on Queue Backlog: By creating a metric based on the backlog per instance calculation, the system can monitor the workload of each instance in the Auto Scaling groups. This allows for dynamic scaling based on the workload, ensuring that additional instances are launched when the backlog increases and terminated when the backlog decreases. Optimization of AWS Resources: This solution optimizes the utilization of AWS resources by dynamically scaling the Auto Scaling groups based on the actual workload, preventing over-provisioning or under-provisioning of instances. It ensures that the system can handle peak traffic efficiently without incurring unnecessary costs.
Comment: D is the most appropriate response base on https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
Comment: D. Provision two Amazon Simple Queue Service (Amazon SQS) queues: one for order collection and another for order fulfillment. Configure the EC2 instances to poll their respective queue. Create a metric based on a backlog per instance calculation. Scale the Auto Scaling groups based on this metric.
Comment: SQS auto-scales by default so I don't think we need to mention it explicitly. Option D should be correct.
Comment: A. This approach focuses solely on CPU utilization, which may not accurately reflect the scaling needs of the order collection and fulfillment processes. It does not address the need for decoupling and reliable message processing. B. While this approach incorporates alarms to trigger additional Auto Scaling groups, it lacks the decoupling and reliable message processing provided by using SQS queues. It may lead to inefficient scaling and potential data loss. C. Although using SQS queues is a step in the right direction, scaling solely based on queue notifications may not provide optimal resource utilization. It does not consider the backlog per instance and does not allow for fine-grained control over scaling. Overall, option D, which involves using SQS queues for order collection and fulfillment, creating a metric based on backlog per instance calculation, and scaling the Auto Scaling groups accordingly, is the most suitable solution to address the scaling problems while optimizing resource utilization and ensuring reliable message processing.
Comment: C is incorrect. "based on notifications that the queues send" SQS does not send notification
Comment: D is not correct because it requires more operational overhead and complexity than option C which is simpler and more cost-effective. It uses the existing queue metrics that are provided by Amazon SQS and does not require creating or publishing any custom metrics. You can use target tracking scaling policies to automatically maintain a desired backlog per instance ratio without having to calculate or monitor it yourself.
Comment: "You can use target tracking scaling policies" but you don't with option C. What is "scaling based on notifications that the queues send"? Where do they send these notifications to?
Comment: Scale based on queue length
Comment: answer is D. read question again
Comment: The number of instances in your Auto Scaling group can be driven by how long it takes to process a message and the acceptable amount of latency (queue delay). The solution is to use a backlog per instance metric with the target value being the acceptable backlog per instance to maintain.
Comment: D is correct
Comment: C Need to Auto- Scale Queue of SQS
Comment: Why would you scale based on " Scale the Auto Scaling groups based on notifications that the queues send."? Would it not make 1000 times more sense to scale base don queue length "Create a metric based on a backlog per instance calculation"?
Comment: I think its D as here we are creating new metric to calculate load on each EC2 instance.
Comment: A is not the quickest solution because CloudTrail primarily focuses on capturing and logging API activity. While it can provide information about resource changes, it may not provide a comprehensive and quick way to identify all the tagged components across multiple services and Regions. B involves manually querying each service using the AWS CLI, which can be time-consuming and cumbersome, especially when dealing with multiple services and Regions. It is not the most efficient solution for quickly identifying tagged components. C is focused on analyzing logs rather than directly identifying the tagged components. While CloudWatch Logs Insights can help extract information from logs, it may not provide a straightforward and quick way to gather a consolidated list of all tagged components across different services and Regions. D is the quickest solution as it leverages the Resource Groups Tag Editor, which is specifically designed for managing and organizing resources based on tags. It offers a centralized and efficient approach to generate a report of tagged components across multiple services and Regions.
Comment: Tags are key and value pairs that act as metadata for organizing your AWS resources
Comment: D. Run a query with the AWS Resource Groups Tag Editor to report on the resources globally with the application tag
Comment: A solutions architect can provide the quickest solution for identifying all of the tagged components by running running a query with the AWS Resource Groups Tag Editor to report on the resources globally with the application tag, hence the option D is right answer.
Comment: The answer is D
Comment: D가 맞습니다.
Comment: https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html
Comment: Answer is D.
Comment: validated https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html
Comment: D is correct
Comment: https://www.examtopics.com/discussions/amazon/view/51352-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: S3 Intelligent-Tiering monitors access patterns and moves objects that have not been accessed for 30 consecutive days to the Infrequent Access tier and after 90 days of no access to the Archive Instant Access tier.
Comment: https://aws.amazon.com/getting-started/hands-on/getting-started-using-amazon-s3-intelligent-tiering/
Comment: I think it cannot be clearly answered because we know that the 'access pattern is variable and changes rapidly', but ultimately it depends on the total number and volume of accesses. All four options meet the "not increase retrieval time" requirement (even Glacier Instant Retrieval has "the same latency and access time as S3 Standard"). If data would be rarely accessed, B would be cheapest. If it would be constantly accessed, C would be cheapest (we'd pay the Intelligent Tiering fee but it would never move anything to a cheaper tier). Inbetween it would be D. But I guess the key is Amazon's clear recommendation to use Intelligent Tiering (A) for "unknown or changing access" patterns, which matches the statement in the question.
Comment: Instant
Comment: unknown / changing access patterns = intelligent tiering. memorise
Comment: Unpredictable access pattern - Intelligent tiering
Comment: Correct Answer A: When data access pattern is not known then Intelligent-tiering can help by monitoring data-access pattern and move object internally accordingly an still ensure faster retrieval. Also There is no object retrieval fees/changes for S3 Intelligent Tier(So cost savings). Option C is not a valid answer because name itself says Infrequent Access(IA): S3 Standard-IA is for data that is accessed less frequently.
Comment: Immediate Availability: S3 Standard provides immediate access to the data upon upload. This ensures that the exported database is immediately available for other teams to access without any retrieval delays. Variable Access Pattern: S3 Standard is designed to handle variable access patterns efficiently. It can accommodate rapid changes in access patterns without any impact on performance or latency. Retention Period: S3 Standard is suitable for storing data that needs to remain accessible for up to 3 months. It does not have any retrieval fees or delays, making it ideal for this scenario where immediate access is required.
Comment: Feels like half the scenario or answers are missing. Where's the "remove objects after 90 days"? Intelligent Tiering has an upcharge for the provided convenience - does it even make sense, when objects won't remain long enough to be archived? Other classes trade storage cost for request costs. Dependent on how often objects are queried, IA might make sense. Even Glacier Instant Retrieval could come out ahead, given minimal access (and it has 90 days minimum storage duration, exact fit for the description). With no further details provided, this is just throwing darts blindly.
Comment: Given just the uncertain access patterns AND limited storage time, I would argue in favor of simple S3 Standard. If the question mentioned that the pattern of access varies across objects, but is relatively consistent for the individual objects, intelligent tiering may be worth it. Otherwise you just pay more to have objects monitored for Infrequent Access, and then suddenly become popular after being moved.
Comment: A is the perfect answer - The S3 access pattern for the data is variable and changes rapidly.
Comment: With regard to "The S3 access pattern for the data is variable and changes rapidly" Even though Answer B cooudl fifull some requirements, Answer A is For long-lived data that have unpredictable access patterns.
Comment: "immediately available" => D is not immediately, and for cost B < A/C
Comment: Selected Answer: B https://aws.amazon.com/s3/storage-classes/glacier/instant-retrieval/ "Amazon S3 Glacier Instant Retrieval is an archive storage class that delivers the lowest-cost storage for long-lived data that is rarely accessed and requires retrieval in milliseconds"
Comment: A. El patrón de acceso a los datos es variable y cambia rápidamente = S3 Intelligent-Tiering
Comment: very important note , S3 Intelligent-Tiering got no retrival charges
Comment: access pattern for the data is variable and changes rapidly = S3 Intelligent-Tiering
Comment: There are 2 viable options A and C. The Intelligent tearing(A) might put your data in the archive or Infrequent Acces if it is not used for 80 days and then used as crazy for the last 10 days of the period which will cause delays in retrieval or the costs associated with traffic. Option C can be optimised with the Time To Live policy of 90 days and will e the most efficient and reliable solution to satisfy the needs.
Comment: Lifecycle policies apply to all tiers, you can have data deleted or archived after 3 months regardless whether it is in Standard or Intelligent-Tiering.
Comment: Has to be C. S3 Intelligent-Tiering is for data with varying or unknown access needs. Not the case here. We know data must be highly available for 30 days.
Comment: Isn't "varying or unknown access needs" the same as "the access pattern is variable and changes rapidly"?
Comment: C --- Read and understand the question. *The company needs to reduce its share of responsibility in managing, updating, and securing servers for its AWS environment* Go with AWS Shield advanced --This is a managed service that includes AWS WAF, custom mitigations, and DDoS insight.
Comment: Have you read and understood the question first!! It says application-level attacks such as cross -site scripting, SQL injection which automatically points to AWS WAF Go to this link and look at AWS WAF benefits https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
Comment: WRONG. Answer is A. Don't let all these upvotes fool you
Comment: I dont know how this comment gets 11x upvotes. A.To filter traffic and protect against application attacks like cross-site scripting and SQL injection, the company can use AWS Web Application Firewall with managed rules on the Application Load Balancer. This provides security with minimal infrastructure and operations overhead.
Comment: Brother answer is A, Read the question once again or ask CHATGPT for more in-depth analysis
Comment: By configuring AWS WAF rules and associating them with the ALB, the company can filter and block malicious traffic before it reaches the application. AWS WAF offers pre-configured rule sets and allows custom rule creation to protect against common vulnerabilities like XSS and SQL injection. Option B does not provide the necessary security and traffic filtering capabilities to protect against application-level attacks. It is more suitable for hosting static content rather than implementing security measures. Option C is focused on DDoS protection rather than application-level attacks like XSS or SQL injection. While AWS Shield Advanced does not address the specific requirements mentioned in the scenario. Option D involves maintaining and securing additional infrastructure, which goes against the requirement of reducing responsibility and relying on minimal operational staff.
Comment: Most of all, A and C are both available technically, right? So the point of question is not about technical posibility. Its about "share of the respoinsibility" which is intended to ask of which service provides "Support Plan" - AWS Shield Response Team (SRT)
Comment: A for sure
Comment: AWS Shield Advanced for DDoS Attacks and not SQL injection which is protected by AWS WAF
Comment: AWS WAF with managed rules.
Comment: Explanation: Option A: AWS WAF (Web Application Firewall) provides protection against common web exploits by allowing you to create rules that block common attack patterns such as SQL injection and cross-site scripting (XSS). By associating AWS WAF rules with the ALB, you can protect your application from these types of attacks without managing, updating, and securing servers yourself. AWS WAF is a managed service, so it reduces the operational overhead for the company. Option C: AWS Shield Advanced provides DDoS protection, but it doesn't include application-level protection like AWS WAF does.
Comment: If you read SQL Injection, Cross-site scripting >>> Always look for: WAF
Comment: This is confusing "The company needs to reduce its share of the responsibility in managing, updating, and securing servers for its AWS environment." But could be acheived when using WAF and AWS managed Rules.
Comment: A is the answer.
Comment: AWS Shield Advanced does not directly protect against XSS (cross-site scripting) or SQL injection attacks. It focuses on defending against Distributed Denial of Service (DDoS) attacks, which aim to overwhelm resources and disrupt availability.
Comment: S makes more sense as Shield Advanced (which actually contains WAF) doesn't provide any additional benefits apart from networks protection. WAF will still have to be configured. So just use WAF to fulfil the requirements.
Comment: You need to "configure AWS WAF rules and associate them with the ALB" which is A. AWS Shield Advance INTEGRATES with WAF, so you can manage WAF through Shield Advanced, but still you would need to set it up and configure rules, which C does not mention.
Comment: AWS Shield is not only DDos and it handle Layer 3 and layer 4 including AWS WAF so C should match.
Comment: "Shield Advanced provides ... integration (!) with AWS WAF", but you still need WAF. And you need WAF rules, whereever you configure them.
Comment: AWS WAF helps you protect against common web exploits and bots that can affect availability, compromise security, or consume excessive resources. Protect against vulnerabilities and exploits such as SQL injection or Cross site scripting attacks.
Comment: To filter traffic and protect against application attacks like cross-site scripting and SQL injection, the company can use AWS Web Application Firewall with managed rules on the Application Load Balancer. This provides security with minimal infrastructure and operations overhead.
Comment: To achieve proper traffic filtering and protect the Application Load Balancer (ALB) against common application-level attacks, such as cross-site scripting (XSS) or SQL injection, while minimizing infrastructure and operational overhead, the company can consider using AWS Web Application Firewall (WAF) with AWS Managed Rules.
Comment: It looks like AWS Glue allows fully managed CSV to Parquet conversion jobs: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/three-aws-glue-etl-job-types-for-converting-data-to-apache-parquet.html
Comment: A text book use case: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/three-aws-glue-etl-job-types-for-converting-data-to-apache-parquet.html#three-aws-glue-etl-job-types-for-converting-data-to-apache-parquet-epics B is the correct answer.
Comment: AWS Glue is a fully managed ETL service that simplifies the process of preparing and transforming data for analytics. Using AWS Glue requires minimal development effort compared to the other options. Option A requires more development effort as it involves writing a Spark application to transform the data. It also introduces additional infrastructure management with the EMR cluster. Option C requires writing and managing custom Bash scripts for data transformation. It requires more manual effort and does not provide the built-in capabilities of AWS Glue for data transformation. Option D requires developing and managing a custom Lambda for data transformation. While Lambda can handle the transformation, it requires more effort compared to AWS Glue, which is specifically designed for ETL operations. Therefore, option B provides the easiest and least development effort by leveraging AWS Glue's capabilities for data discovery, transformation, and output to the transformed data bucket.
Comment: AWS Glue and parquet go hand in hand
Comment: i will go with answer B cause: You can use AWS Glue to write ETL jobs in a Python shell environment. You can also create both batch and streaming ETL jobs by using Python (PySpark) or Scala in a managed Apache Spark environment. Apache Parquet is built to support efficient compression and encoding schemes. It can speed up your analytics workloads because it stores data in a columnar fashion. Converting data to Parquet can save you storage space, cost, and time in the longer run
Comment: D I think people are forgetting the question says "Low Overhead".
Comment: Pray tell, how is a Lambda less overhead than B or even A?
Comment: Parquet format ========> Amazon Glue
Comment: B. Create an AWS Glue crawler to discover the data. Create an AWS Glue extract, transform, and load (ETL) job to transform the data. Specify the transformed data bucket in the output step.
Comment: Least development effort means lambda. Glue also works but more overhead and cost. A simple lambda like this https://github.com/ayshaysha/aws-csv-to-parquet-converter/blob/main/csv-parquet-converter.py can be used to convert as soon as you see files in s3 bucket.
Comment: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/three-aws-glue-etl-job-types-for-converting-data-to-apache-parquet.html
Comment: S3 provides a single control to automatically encrypt all new objects in a bucket with SSE-S3 or SSE-KMS. Unfortunately, these controls only affect new objects. If your bucket already contains millions of unencrypted objects, then turning on automatic encryption does not make your bucket secure as the unencrypted objects remain. For S3 buckets with a large number of objects (millions to billions), use Amazon S3 Inventory to get a list of the unencrypted objects, and Amazon S3 Batch Operations to encrypt the large number of old, unencrypted files.
Comment: Please delete this. I was meaning to place this response on a different question.
Comment: Versioning: When you overwrite an S3 object, it results in a new object version in the bucket. However, this will not remove the old unencrypted versions of the object. If you do not delete the old version of your newly encrypted objects, you will be charged for the storage of both versions of the objects. S3 Lifecycle If you want to remove these unencrypted versions, use S3 Lifecycle to expire previous versions of objects. When you add a Lifecycle configuration to a bucket, the configuration rules apply to both existing objects and objects added later. C is missing this step, which I believe is what makes B the better choice. B includes the functionality of encrypting the old unencrypted objects via Batch Operations, whereas, Versioning does not address the old unencrypted objects.
Comment: Please delete this. I was meaning to place this response on a different question.
Comment: ETL = Glue
Comment: B is the correct answer
Comment: AWS Glue Crawler is for ETL
Comment: The correct answer is B
Comment: B is the answer
Comment: ıt should be b
Comment: De acordo com a documentação, a resposta certa é B. https://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/three-aws-glue-etl-job-types-for-converting-data-to-apache-parquet.html
Comment: hundreds of Terabytes => always use Snowball
Comment: Terabytes, low costs, limited time = AWS snowball devices
Comment: It took me quite some time to do the mental math for realising that the data can't be transferred in 30 days. Also, note the MBps (Megabits) and not Megabytes. 500Mbps is like 60MBps. That's a lame connection to transfer anything!
Comment: well.. standard internet connections are measured in Mbps and 500 Mbps is pretty decent to be fair (by english standards). even still at that speed it would take you about 4 months to upload 700 TB. So the only option here is to use snowball. Answer is A
Comment: B and D would use existing 500 mbps Internet connection which cannot transfer more than ca. 160 TB in a month. C would cost a lot, take weeks to deliver, and still not provide more bandwidth. Thus A is the simply the only option, thus also the one with "lowest cost".
Comment: A. Order AWS Snowball devices to transfer the data. Use a lifecycle policy to transition the files to Amazon S3 Glacier Deep Archive.
Comment: one DataSync agent can use 10GBps and can setup a bandwidth. So total time = (700X1000)GB/10GBps = 70000 sec = 19.4 days. Using Multiple Snowball devices will involve ordering them from AWS, setting them up on your data-center for copy and then incurring the shipping cost for too and fro movement to your AWS cloud. if time constraint was critical , say 1 week then snowball would have been a viable option. But here we have 30 days, so DataSync will be less costly(takes `19days)
Comment: your math is wrong mate, and they have 0.5Gbps connection, not 10GBps 500Mpbs = roughly 60MBps 30x24x3600x0.06TB = roughly 155TB this is way short of 700TB
Comment: By ordering Snowball devices, the company can transfer the 700 TB of backup data from its data center to AWS. Once the data is transferred to S3, a lifecycle policy can be applied to automatically transition the files from the S3 Standard storage class to the cost-effective Amazon S3 Glacier Deep Archive storage class. Option B would require continuous data transfer over the public internet, which could be time-consuming and costly given the large amount of data. It may also require significant bandwidth allocation. Option C would involve additional costs for provisioning and maintaining the dedicated connection, which may not be necessary for a one-time data migration. Option D could be a viable option, but it may incur additional costs for deploying and managing the DataSync agent. Therefore, option A is the recommended choice as it provides a secure and efficient data transfer method using Snowball devices and allows for cost optimization through lifecycle policies by transitioning the data to S3 Glacier Deep Archive for long-term storage.
Comment: A is the correct answer. even though they have 500mbps internetspeed, it will take around 130days to transfer the data from on premises to AWS so they have only 1 option which is Snowball devices
Comment: A is the correct one
Comment: Q: What is AWS Snowball Edge? AWS Snowball Edge is an edge computing and data transfer device provided by the AWS Snowball service. It has on-board storage and compute power that provides select AWS services for use in edge locations. Snowball Edge comes in two options, Storage Optimized and Compute Optimized, to support local data processing and collection in disconnected environments such as ships, windmills, and remote factories. Learn more about its features here. Q: What happened with the original 50 TB and 80 TB AWS Snowball devices? The original Snowball devices were transitioned out of service and Snowball Edge Storage Optimized are now the primary devices used for data transfer. Q: Can I still order the original Snowball 50 TB and 80 TB devices? No. For data transfer needs now, please select the Snowball Edge Storage Optimized devices.
Comment: Snowball
Comment: 9 Snowball devices are needed to migrate the 700TB of data.
Comment: 700TB of Data can not be transferred through a 500Mbps link within one month. Total data that can be transferred in one month = bandwidth x time = (500 Mbps / 8 bits per byte) x (30 days x 24 hours x 3600 seconds per hour) = 648,000 GB or 648 TB This is calculated theoretically with the maximum available situation. Due to a number of factors, the actual total transferred Data may be less than 645 TB.
Comment: Good thinking. Agree with the solution. Only the calculation is wrong. It should give 162tb as a result
Comment: Snow ball Devices the answe is AAAAA.
Comment: A is incorrect as DC is an expensive option. Correct answer should be C as the company already has 500Mbps that can be used for data transfer. By consuming all the available internet bandwidth, data transfer will complete in 3 hours 6 mins - https://www.omnicalculator.com/other/data-transfer
Comment: Ignore please, miscalculated time to transfer, it will take 129 days and will breach the 1 month requirement. A is correct.
Comment: A is correct
Comment: a is correct but not less expensive.I think,should be D.
Comment: Does not work in a month
Comment: A is correct. Cannot copy files directly from on-prem to S3 Glacier with DataSync. It should be S3 standard first, then configuration S3 Lifecycle to transit to Glacier => Exclude D.
Comment: yes you can - https://docs.aws.amazon.com/datasync/latest/userguide/create-s3-location.html#using-storage-classes
Comment: Step 1: S3 inventory to get object list Step 2 (If needed): Use S3 Select to filter Step 3: S3 object operations to encrypt the unencrypted objects. On the going object use default encryption.
Comment: Useful ref link: https://aws.amazon.com/blogs/storage/encrypting-objects-with-amazon-s3-batch-operations/
Comment: By enabling default encryption settings on the S3, all newly added objects will be automatically encrypted. To encrypt the existing objects, the S3 Inventory feature can be used to generate a list of unencrypted objects. Then, an S3 Batch Operations job can be executed to copy those objects while applying encryption. A. This solution involves creating a new S3 and manually downloading and uploading all existing objects. It requires significant effort and time to transfer millions of objects, making it a less efficient solution. C. While enabling SSE with AWS KMS is a valid approach to encrypt objects in an S3, it does not address the requirement of encrypting existing objects. It only applies encryption to new objects added to the bucket. D. Manually modifying each object in the S3 to apply default encryption settings is a labor-intensive and error-prone process. It would require individually selecting and modifying each unencrypted object, which is impractical for a large number of objects.
Comment: to be fair all these options take a hell a lot of work to do but i think the least amount of effort is B. https://aws.amazon.com/blogs/storage/encrypting-objects-with-amazon-s3-batch-operations/
Comment: A - Extreme amount of effort B - Should work C - SSE-KMS is not "least amount of effort" compared to SSE-S3; Turning versioning is not required to achieve the result but on the contrary, it will cause the non-encrypted files to remain as old versions even if you encrypt them in the future. D - Even more effort as A
Comment: .csv for millions of objects ?? C looks simpler.
Comment: B doesnt look like least amount of effort
Comment: B... https://catalog.us-east-1.prod.workshops.aws/workshops/05f16f1a-0bbf-45a7-a304-4fcd7fca3d1f/en-US/s3-track/module-2 You're welcome
Comment: Amazon S3 now configures default encryption on all existing unencrypted buckets to apply server-side encryption with S3 managed keys (SSE-S3) as the base level of encryption for new objects uploaded to these buckets. Objects that are already in an existing unencrypted bucket won't be automatically encrypted. https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-encryption-faq.html
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops-copy-example-bucket-key.html
Comment: B is the correct answer
Comment: B 100% https://spin.atomicobject.com/2020/09/15/aws-s3-encrypt-existing-objects/
Comment: Why is no one discussing A ? I think A can also achieve the required results. B is the most appropriate answer though.
Comment: Downloading and uploading "millions of objects" is surely not "least amount of effort", thus does not meet the requirements.
Comment: S3 provides a single control to automatically encrypt all new objects in a bucket with SSE-S3 or SSE-KMS. Unfortunately, these controls only affect new objects. If your bucket already contains millions of unencrypted objects, then turning on automatic encryption does not make your bucket secure as the unencrypted objects remain. For S3 buckets with a large number of objects (millions to billions), use Amazon S3 Inventory to get a list of the unencrypted objects, and Amazon S3 Batch Operations to encrypt the large number of old, unencrypted files.
Comment: Versioning: When you overwrite an S3 object, it results in a new object version in the bucket. However, this will not remove the old unencrypted versions of the object. If you do not delete the old version of your newly encrypted objects, you will be charged for the storage of both versions of the objects. S3 Lifecycle If you want to remove these unencrypted versions, use S3 Lifecycle to expire previous versions of objects. When you add a Lifecycle configuration to a bucket, the configuration rules apply to both existing objects and objects added later. C is missing this step, which I believe is what makes B the better choice. B includes the functionality of encrypting the old unencrypted objects via Batch Operations, whereas, Versioning does not address the old unencrypted objects.
Comment: S3 provides a single control to automatically encrypt all new objects in a bucket with SSE-S3 or SSE-KMS. Unfortunately, these controls only affect new objects. If your bucket already contains millions of unencrypted objects, then turning on automatic encryption does not make your bucket secure as the unencrypted objects remain. For S3 buckets with a large number of objects (millions to billions), use Amazon S3 Inventory to get a list of the unencrypted objects, and Amazon S3 Batch Operations to encrypt the large number of old, unencrypted files.
Comment: Versioning: When you overwrite an S3 object, it results in a new object version in the bucket. However, this will not remove the old unencrypted versions of the object. If you do not delete the old version of your newly encrypted objects, you will be charged for the storage of both versions of the objects. S3 Lifecycle If you want to remove these unencrypted versions, use S3 Lifecycle to expire previous versions of objects. When you add a Lifecycle configuration to a bucket, the configuration rules apply to both existing objects and objects added later. C is missing this step, which I believe is what makes B the better choice. B includes the functionality of encrypting the old unencrypted objects via Batch Operations, whereas, Versioning does not address the old unencrypted objects.
Comment: Please remove duplicate response as I was meaning to submit a voting comment.
Comment: C is wrong. Even though you turn on the SSE-KMS with a new key, the existing objects are still yet to be encrypted. They still need to be manually encrypted by AWS batch
Comment: And as in C you "turn on versioning", the old, unencrypted objects will be kept.
Comment: https://spin.atomicobject.com/2020/09/15/aws-s3-encrypt-existing-objects/
Comment: C is the answer
Comment: Why? This does not include a step to encrypt existing objects, and by turning on versioning you will keep the unencrypted versions forever.
Comment: Agree with Parsons
Comment: the answer is C also, the questions require future encryption of the objects is the S3 bucket = VERSIONING
Comment: Huh? "future encryption of objects = versioning"??????
Comment: Actually it's the opposite. Versioning will keep the unencrypted objects as previous versions, even if you encrypt them.
Comment: A is correct. - "The solution does not need to handle the load when the primary infrastructure is healthy." => Should use Route 53 Active-Passive ==> Exclude B, C - D is incorrect because "Create an Aurora second primary instance in the second Region.", we need to create an Aurora Replica enough.
Comment: Ref link: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-types.html
Comment: Anything that is not instant recovery is active - passive. In active -passive we have : 1. Aws Backup(least op overhead) - RTO/RPO = hours 2. Pilot Light ( Basic Infra is already deployed, but needs to be fully implemented) -RTO/RPO = 10's of minutes. 3. Warm Standby- (Basic infra + runs small loads ( might need to add auto scaling) -RTO/RPO= minutes 4. ( ACTIVE -ACTIVE ) : Multi AZ option : instant here we can tolerate 30 mins hence B,D are incorrect. AWS backup is in hours, hence D is incorrect . therefore A
Comment: A does not create the infrastructure in the DR region though.
Comment: D is right
Comment: confused with A and D but D looks more promising when it says doesn't need to handle the load when primary infrastructure is healthy
Comment: I went for D as the wording of A is weird.... D seems most plausible
Comment: A For those you are choosing D, I have a question for you. How do you guarantee the provisioning of resources will take less than 30 min through AWS Backup?
Comment: By excluding other options you can choose A but this option is incomplete as it doesn't mention deploying/recovering the application in secondary region.
Comment: A is perfect - Active-Passive Failover: Use this failover configuration when you want a primary group of resources to be available the majority of the time and you want a secondary group of resources to be on standby in case all of the primary resources become unavailable.
Comment: A is perfect
Comment: Here's why the other options aren't as suitable: B. Active-active failover: Incur higher costs due to running both infrastructures simultaneously and introduces complexity in managing traffic distribution. C. Restoring from snapshot: Could take longer than 30 minutes to recover, exceeding the company's downtime tolerance. D. AWS Backup: Dependent on backup and restore times, potentially exceeding the 30-minute recovery window.
Comment: Not A - does not mention a second region for the infrastructure elements. Also, you cannot really "create an Aurora Replica in a second AWS Region", replicas must be in same region unless using Aurora Global Database (which is not mentioned) Not B - would send half of the traffic to the DR region Not C - this could send traffic to the DR instance even when the primary instance is healthy D - the wording "Aurora second primary instance" is a bit strange, but still a "primary instance" is what we would need in the other region. We would still need to establish replication between the databases (like binlog), or restore a snapshot before failover, but in general this option could meet the 30 minute RTO/RPO requirement.
Comment: the question doesnt state Aurora MySQL but you can set up cross-region replicas for Aurora MySQL, but not PostgreSQL. the question only says Amazon Aurora, so its left a bit open as Aurora is either MySql or PostgreSQL. this is without using Global Database. tbh i think this question and answers are well off... it is a dump after all.
Comment: I agreed with D as the requirements of 30 min downtime and potential data loss and no load consideration when primary instance is healthy. It makes D more feasible than A. Aurora-Replica is normally used for active-active failovers. Be frugal!
Comment: If this is the quality of the questions in exam, then we are all screwed! I don't think any options are correct. A proabably the most correct, but a big flaw. "Deploy the application with the required infrastructure elements in place." Deploy to where? Fair enough if you assume another region/AZ, but it's not stated and only Aurora replica is mentioned, not the Web/app servers etc.
Comment: I really hope the language is better in the exams. Option A is like "do what it takes it to make the solution work".... well then by default it is right until the second part makes it wrong. smh!
Comment: 'Can tolerate up to 30 minutes of downtime and potential data loss' rules out any option with 'active-active'. Leaves D and A. D is convoluted. Leaving A.
Comment: A. involves deploying the application and infrastructure elements in the primary Region. An Aurora Replica is created in a second Region to serve as the standby database. Route 53 is configured with active-passive failover, directing traffic to the primary Region by default. In the event of a disaster, Route 53 can automatically redirect traffic to the standby Region, minimizing downtime. Data loss may occur up to the point of the last replication to the standby Region, which can be within the defined tolerance of 30 minutes. Option B, is not necessary in this case as the solution does not need to handle the load when the primary infrastructure is healthy, and it may involve higher complexity and costs. Option C, may introduce additional complexity and potential data loss, as the standby database might not be up-to-date with the primary database. Option D, may be suitable for backup and recovery scenarios but may not provide the required failover and downtime tolerance specified in the requirements.
Comment: I vote D, because option A is not highly available. In option A, you can't configure active-passive failover because you haven't created a backup infrastructure.
Comment: It is a cross region DR strategy. You need a read replica and Application in another region to have a realistic DR option. The read replica will take few minutes to to promoted/Active and the application is available. Option D lacks clarity on application and Backups can take time to restore.
Comment: A, E is perfect the combination. To be more precise, We should add outbound with "outbound TCP port 32768-65535 to destination 0.0.0.0/0." as an ephemeral port due to the stateless of NACL.
Comment: What is the main reason that you are using the TCP port 32768-65535> In the question, it doesn't ask you any requirement about it.
Comment: i Think AD because acl is stateless we must open the port outbound and inbound , in option c we only open 443 on inbound
Comment: i Think AD because acl is stateless we must open the port outbound and inbound , in option E we only open 443 on inbound
Comment: For me it's grammatically unclear whether "port 443" and "port 32768-65535" in answers D and E are referring to the source or destination ports of the outbound traffic. If source ports then it would be D. If destination ports (which seems more likely) then it's E. "On Windows, the ephemeral port range is usually from 49152 to 65535. On Linux, it is often from 32768 to 61000." Thus 32768-65535 would cover both Windows and Linux.
Comment: Option A: Creating a security group that allows inbound traffic on TCP port 443 from all sources (0.0.0.0/0) ensures that the web server can accept incoming HTTPS requests. Option D: Updating the network ACL to allow inbound traffic on TCP port 443 from all sources (0.0.0.0/0) allows the requests to reach the EC2 instance. Additionally, it is necessary to allow outbound traffic on TCP port 443 to enable responses to clients, which is crucial for HTTPS communication.
Comment: Higher priority NACL to allow inbound and outbound traffic on 443 with take the precedence over default blocked NACL
Comment: AD How can E be the answer. How can we assure that the port range is definitely from the given port range in the option E?
Comment: Security group only needs inbound rules. ACL needs inbound and outbound.. Outbound traffic is going to be dynamic ports. Answer is A and E
Comment: AE Security group is a stateful resource and can understand to allow traffic from source 0.0.0.0/0 with port 443 but ACL is stateless so traffic that is allowed inside the network we must configure the same to go outside the network as well.
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-basics "NACLs are stateless, which means that information about previously sent or received traffic is not saved. If, for example, you create a NACL rule to allow specific inbound traffic to a subnet, responses to that traffic are not automatically allowed. This is in contrast to how security groups work. Security groups are stateful, which means that information about previously sent or received traffic is saved. If, for example, a security group allows inbound traffic to an EC2 instance, responses are automatically allowed regardless of outbound security group rules." A fulfils the security group requirement E is the only option that explicitly covers outbound traffic and ports. D covers outbound destination but given that all traffic is blocked (as per the question) this won't work
Comment: For typical web server scenarios, such as serving content over HTTPS (port 443), you generally do not need to explicitly open outbound ports in the network ACL (NACL) for the return traffic.
Comment: But NACLs are stateless."The default network ACL has been modified to block all traffic"; if you don't allow any outbound traffic then the web server won't be able to reply to clients.
Comment: ACL is stateless. you have to define both inbound and outbound rules.
Comment: i Think AD because acl is stateless we must open the port outbound and inbound , in option c we only open 443 on inbound
Comment: i Think AD because acl is stateless we must open the port outbound and inbound , in option D we only open 443 on inbound
Comment: please admin delete this , sorry
Comment: please admin delete this , sorry
Comment: A, E is perfect the combination. To be more precise, We should add outbound with "outbound TCP port 32768-65535 to destination 0.0.0.0/0." as an ephemeral port due to the stateless of NACL.
Comment: AE is the best answer here, but in reality, E is not good enough. Here, it says that the client chooses the ephemeral port, and it can start from 1024. Only Linux clients have the range starting at 32768 https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports Unless the destination advertises the ephemeral ports, which I don't think is the case
Comment: "On Windows, the ephemeral port range is usually from 49152 to 65535. On Linux, it is often from 32768 to 61000." Combined: 32768 - 65535 ...
Comment: AE is the best answer here, but in reality, E is not good enough. Here, it says that the client chooses the ephemeral port, and it can start from 1024. Only Linux clients have the range starting at 32768 https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports Unless the destination advertises the ephemeral ports, which I don't think is the case
Comment: 32768-65535 ports Allows outbound IPv4 responses to clients on the internet (for example, serving webpages to people visiting the web servers in the subnet).
Comment: NACL blocks outgoing traffic since it is infact stateless..Option E allows outbound traffic from ephemeral ports going outside of the VPC back to the web.
Comment: It can't be C, since the current NACL blocks all traffic, including outbound. Need to allow outbound traffic through the NACL. But E is a bad answer, since ephemeral ports start at 1024, not 32768.
Comment: D is the correct answer. "in-memory tasks" => need the "R" EC2 instance type to archive memory optimization. So we are concerned about C & D. Because EC2 instances don't have built-in memory metrics to CW by default. As a result, we have to install the CW agent to archive the purpose.
Comment: It's D, EC2 do not provide by default memory metrics to CloudWatch and require the CloudWatch Agent to be installed on the monitored instances : https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-memory-metrics-ec2/
Comment: how future capacity planning and just do verticall scalling will improve the performance. Question doesn't specify if these EC2 are behind auto scalling so it means they are not. out of all A seems more close to the solution
Comment: B will reduce operational overhead and better solution than keep changing the family. Also, I don't think the exam will require you to remember instance families like M5 and R5
Comment: D .....
Comment: R5 instances are better optimized for the in-memory workload than M5. Auto Scaling alone doesn't handle stateful applications well, manual capacity adjustments would still be needed. Custom latency metrics give better visibility than built-in metrics for capacity planning.
Comment: By replacing the M5 instances with R5 instances, which are optimized for memory-intensive workloads, the application can benefit from increased memory capacity and performance. In addition, deploying the CloudWatch agent on the EC2 instances allows for the generation of custom application latency metrics, which can provide valuable insights into the application's performance. This solution addresses the performance issues efficiently by leveraging the appropriate instance types and collecting custom application metrics for better monitoring and future capacity planning. A. Replacing with T3 instances may not provide enough memory capacity for in-memory tasks. B. Manually increasing the capacity of the ASG does not directly address the performance issues. C. Relying solely on built-in EC2 memory metrics may not provide enough granularity for optimizing in-memory tasks. The most efficient solution is to modify the CloudFormation templates, replace with R5 instances, and deploy the CloudWatch agent for custom metrics.
Comment: Option D is the correct answer.
Comment: will go for C
Comment: Would go with D
Comment: ı think D
Comment: B is the correct answer. API Gateway + Lambda is the perfect solution for modern applications with serverless architecture.
Comment: Screaming Lambda
Comment: data processing should be completed within a few seconds = An AWS Lambda function
Comment: B. An AWS Lambda function
Comment: lambda is expensive than running ECS on EC2
Comment: "Several hours can pass without receiving a single request", during which Lambda costs 0.00.
Comment: Lambda all the way.
Comment: Lambda is a serverless compute service that can be triggered by API Gateway to process requests asynchronously. It automatically scales based on the incoming request volume and allows for cost optimization by charging only for the actual compute time used to process the requests. A. Glue is a fully managed ETL service. It is designed for data processing and transformation tasks rather than serving API requests. It may not be suitable for handling variable request volumes and delivering responses within a few seconds. C. While EKS provides scalability and flexibility, it may introduce additional complexity and overhead for managing and scaling the infrastructure for handling variable API request volumes. D. Similar to the previous option, using ECS with EC2 would require additional effort for infrastructure management and scaling, which may not be necessary for handling intermittent and variable API request volumes.
Comment: Option B meets the requirements.
Comment: Lambda !
Comment: https://www.examtopics.com/discussions/amazon/view/43780-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A. EBS provides block-level storage volumes for use with EC2 instances. While it offers durability and persistence, it is not the most cost-effective solution for long-term retention of log files. Additionally, it does not provide concurrent access to the files, which is a requirement in this scenario. B. EFS is a scalable file storage service that can be mounted on multiple EC2 instances concurrently. While it provides concurrent access to files, it may not be the most cost-effective option for long-term retention due to its higher pricing compared to S3. C. The instance store is a temporary storage option that is physically attached to the EC2 instance. It does not provide the durability and long-term retention required for compliance purposes. Additionally, the instance store is not accessible outside of the specific EC2 instance it is attached to, so concurrent access by the reporting tool would not be possible. Therefore, considering the requirements for long-term retention, concurrent access, and cost-effectiveness, S3 is the most suitable and cost-effective storage solution.
Comment: A. EBS provides block-level storage volumes for use with EC2 instances. While it offers durability and persistence, it is not the most cost-effective solution for long-term retention of log files. Additionally, it does not provide concurrent access to the files, which is a requirement in this scenario. B. EFS is a scalable file storage service that can be mounted on multiple EC2 instances concurrently. While it provides concurrent access to files, it may not be the most cost-effective option for long-term retention due to its higher pricing compared to S3. C. The instance store is a temporary storage option that is physically attached to the EC2 instance. It does not provide the durability and long-term retention required for compliance purposes. Additionally, the instance store is not accessible outside of the specific EC2 instance it is attached to, so concurrent access by the reporting tool would not be possible.
Comment: this sounds like an expensive solution but if necessary then S3 would be the best
Comment: most cost effective = Amazon S3
Comment: D. Amazon S3
Comment:
s3
Comment:
actually S3 < EBS < EFS, but for EBS you need to pay for the underlying provisioned GB.
If you compare 1 GB then S3 < EBS < EFS but if you have 100GB storage for EBS than EBS is more expensive.
Replies:
Comment: "The log files will be analyzed by a reporting tool that must be able to access all the files concurrently" , so you need to access concurrently to get the logs. So is EFS. Letter B
Comment: https://aws.amazon.com/efs/faq/ EFS is a file storage service for use with Amazon compute (EC2, containers, serverless) and on-premises servers. EFS provides a file system interface, file system access semantics (such as strong consistency and file locking), and concurrently accessible storage for up to thousands of EC2 instances.
Comment: Whenever we see long time storage and no special requirements that needs EFS or FSx, then S3 is the way.
Comment: To meet the requirements of retaining application log files for 7 years and allowing concurrent access by a reporting tool, while also being cost-effective, the recommended storage solution would be D: Amazon S3.
Comment: ddddddddddddddddddd
Comment: What about the keyword "concurrently"? Doesn't this mean EFS?
Comment: Cost Effective: S3
Comment: S3 is enough with the lowest cost perspective.
Comment: https://www.examtopics.com/discussions/amazon/view/22182-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: By creating an IAM role and delegating access to the vendor's IAM role, you establish a trust relationship between accounts. This allows the vendor's automated tool to assume the role in the company's account and access the necessary resources. By attaching the appropriate IAM policies to the role, you can define the precise permissions that the vendor requires for their tool to perform its tasks. This ensures that the vendor has the necessary access without granting them direct IAM access to the company's account. B is incorrect because creating an IAM user with a password would require sharing the credentials with the vendor, which is not recommended for security reasons. C is incorrect because adding the vendor's IAM user to an IAM group in the company's account would not provide a direct and controlled way to delegate access to the vendor's tool. D is incorrect because creating a new identity provider for the vendor's AWS account would not provide a straightforward way to delegate access to the vendor's tool. Identity providers are typically used for federated access using external identity systems.
Comment: A is proper https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html
Comment: Create an IAM role in the company's account to delegate access to the vendor's IAM role. Attach the appropriate IAM policies to the role for the permissions that the vendor requires
Comment: Create an IAM role in the company's account to delegate access to the vendor's IAM role. Attach the appropriate IAM policies to the role for the permissions that the vendor requires
Comment: A. Create an IAM role in the company's account to delegate access to the vendor's IAM role. Attach the appropriate IAM policies to the role for the permissions that the vendor requires.
Comment: ....................................
Comment: Option A fulfill the requirements.
Comment: IAM role is the answer
Comment: A is correct answer.
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html
Comment: A is the correct answer.
Comment: My guess is D: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html
Comment: But your link describes A, not D.
Comment: After seeing D, I didn't even look at option E. its AD correct
Comment: B: Wrong, cannot be a user for EKS C: Not possible as NACL need destination CIDR/ports etc. This is not correct way to connect to DynamoDB E: Not secure AD is correct because you need roles for allowing service permissions and accessing DynamoDB with VPC endpoint is the correct way
Comment: The application needs to write data to an Amazon DynamoDB table = Attach an IAM role that has write privileges to the EKS pod Without exposing traffic to the internet = VPC endpoint for DynamoDB
Comment: The application needs to write data to an Amazon DynamoDB table = Attach an IAM role that has write privileges to the EKS pod Without exposing traffic to the internet = VPC endpoint for DynamoDB
Comment: A. By attaching an IAM role to the EKS pod, you can grant the necessary permissions for the pod to access DynamoDB. The IAM role should have appropriate policies allowing access to the DynamoDB table. D. Creating a VPC endpoint for DynamoDB allows the EKS pod to access DynamoDB privately within the VPC, without the need for internet connectivity. The VPC endpoint provides a direct and secure connection to DynamoDB, eliminating the need for traffic to flow over the internet.
Comment: A. By attaching an IAM role to the EKS pod, you can grant the necessary permissions for the pod to access DynamoDB. The IAM role should have appropriate policies allowing access to the DynamoDB table. D. Creating a VPC endpoint for DynamoDB allows the EKS pod to access DynamoDB privately within the VPC, without the need for internet connectivity. The VPC endpoint provides a direct and secure connection to DynamoDB, eliminating the need for traffic to flow over the internet. B is incorrect because attaching an IAM user to the pod is not a recommended approach. IAM users are meant for accessing AWS services through the AWS Management Console or AP. C is incorrect because configuring outbound connectivity through network ACLs would not provide a secure and direct connection to DynamoDB. E is incorrect because embedding access keys in the code is not a recommended security practice. It can lead to potential security vulnerabilities. It is better to use IAM roles or other secure mechanisms for providing access to AWS services.
Comment: A & D options fulfill the requirements.
Comment: Definitely
Comment: A D are the correct options
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html https://aws.amazon.com/about-aws/whats-new/2019/09/amazon-eks-adds-support-to-assign-iam-permissions-to-kubernetes-service-accounts/
Comment: A, D is the correct answer.
Comment: The correct answer is A,D
Comment: C. A multivalue answer routing policy in Route 53 allows you to configure multiple values for a DNS record, and Route 53 responds to DNS queries with multiple random values. This enables the distribution of traffic randomly among the available EC2 instances. E. By launching EC2 instances in different AZs, you achieve high availability and fault tolerance. Launching four instances (two in each AZ) ensures that there are enough resources to handle the traffic load and maintain the desired level of availability. A. Failover routing is designed to direct traffic to a backup resource or secondary location only when the primary resource or location is unavailable. B. Although a weighted routing policy allows you to distribute traffic across multiple EC2 instances, it does not ensure random distribution. D. While launching instances in multiple AZs is important for fault tolerance, having only three instances does not provide an even distribution of traffic. With only three instances, the traffic may not be evenly distributed, potentially leading to imbalanced resource utilization.
Comment: I went back and rewatched the lectures from Udemy on Weighted and Multi-Value. The lecturer said that Multi-value is *not* as substitute for ELB and he stated that DNS load balancing is a good use case for Weighted routing policies
Comment: Weighted routing based on weight assigned, it can not do randomly choose, please see last sentence of the question choose randomly.
Comment: what about 50 50 weighted ?
Comment: C and E are the correct answers.
Comment: CE is correct
Comment: CE seems good to me due to " highly available and fault tolerant" and following explanation: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-multivalue.html
Comment: Specifically with this requirement : "Traffic must reach all running EC2 instances randomly"
Comment: E: For HA C: Random routing can only be created with multivalue answer routing policy. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-multivalue.html "To route traffic approximately randomly to multiple resources, such as web servers, you create one multivalue answer record for each resource and, optionally, associate a Route 53 health check with each record. "
Comment: C. A multivalue answer routing policy in Route 53 allows you to configure multiple values for a DNS record, and Route 53 responds to DNS queries with multiple random values. This enables the distribution of traffic randomly among the available EC2 instances. E. By launching EC2 instances in different AZs, you achieve high availability and fault tolerance. Launching four instances (two in each AZ) ensures that there are enough resources to handle the traffic load and maintain the desired level of availability. A. Failover routing is designed to direct traffic to a backup resource or secondary location only when the primary resource or location is unavailable. B. Although a weighted routing policy allows you to distribute traffic across multiple EC2 instances, it does not ensure random distribution.
Comment: First I thought it was weighted but after research C is the correct answer : https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
Comment: Multivalue routing can do random load balancing according to the AWS website: To route traffic approximately randomly to multiple resources, such as web servers, you create one multivalue answer record for each resource and, optionally, associate a Route 53 health check with each record. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-multivalue.html
Comment: This questions is so wired , 3 instances nothing wrong with it
Comment: I guess it's the "highly available AND fault tolerant" requirement. If AZ 1 fails, you have only a single server left in the other region.
Comment: Option CE Correct: To route traffic roughly and randomly to multiple resources, such as web servers, you create a multi-value response record for each resource and optionally associate a Route 53 health check with each record. https://disaster-recovery.workshop.aws/en/services/networking/route53/routing-policies/routing-multiple-answer.html
Comment: CE is correct
Comment: Highly available and fault tolerant = two instances in two AZs Route traffic randomly = Amazon Route 53 multivalue answer routing policy
Comment: Multivalue answer routing policy – Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random. You can use multivalue answer routing to create records in a private hosted zone. Weighted routing policy – Use to route traffic to multiple resources in proportions that you specify. You can use weighted routing to create records in a private hosted zone.
Comment: what about 50 50 weighted routing ?
Comment: I chose CE, but couldn't it also be BE? If you set all of the weights to the same, equal value? Wouldn't then the traffic be distributed randomly and evenly among all healthy instances?
Comment: This is "equal distribution", not "random distribution"; think about the differences
Comment: Randomly is the key word
Comment: C: Multi-value To route traffic approximately randomly to multiple resources and have healt check B: Weighted default use for when you need load to one server more than ohter server. if you need for random to all server should be letter in this C options "and weight to all server with same value".
Comment: Petabyte scale- Redshift
Comment: Data ingestion through Kinesis data streams will require manual intervention to provide more shards as data size grows. Kinesis firehose will ingest data with the least operational overhead.
Comment: Kinesis data stream cannot detined to s3
Comment: 1- Kinesis Data Stream provides a fully managed platform for custom data processing and analysis. Or we can say that used for custom data processing and analysis which required more manual intervention. 2- Kinesis Data Firehose simplifies the delivery of streaming data to various destinations without the need for complex transformations. Option B is more suitable for the given scenario.
Comment: Copy-paste from A1975's answer
Comment: always if you have a service that is meant for a specific job, it the correct answer, is logic. "A" is not good enough for this situation
Comment: B. Send activity data to an Amazon Kinesis Data Firehose delivery stream. Configure the stream to deliver the data to an Amazon Redshift cluster.
Comment: Petabyte scale- Redshift
Comment: 1- Kinesis Data Stream provides a fully managed platform for custom data processing and analysis. Or we can say that used for custom data processing and analysis which required more manual intervention. 2- Kinesis Data Firehose simplifies the delivery of streaming data to various destinations without the need for complex transformations. Option B is more suitable for the given scenario.
Comment: Petabyte Scale sounds like Redshift!
Comment: B provides a fully managed and scalable solution for data ingestion and analytics. KDF simplifies the data ingestion process by automatically scaling to handle large volumes of streaming data. It can directly load the data into an Redshift cluster, which is a powerful and fully managed data warehousing solution. A. While Kinesis can handle streaming data, it requires additional processing to load the data into an analytics solution. C. Although S3 and Lambda can handle the storage and processing of data, it requires more manual configuration and management compared to the fully managed solution offered by KDF and Redshift. D. This option involves more operational overhead, as it requires managing and scaling the EC2 instances and RDS database infrastructure manually. Therefore, option B with KDF delivering the data to Redshift cluster offers the most streamlined and operationally efficient solution for ingesting and analyzing the user activity data in the given scenario.
Comment: petabytes in size => redshift
Comment: It's A. Data Stream is better in this case, and you can query data in S3 with Athena
Comment: Data Stream Can't write to S3. That's why B is only left correct answer.
Comment: Answer A… key phrase' least operational overhead' KDF can write to S3 … https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html
Comment: https://aws.amazon.com/streaming-data/ a good explanation of either option. firehose appears to be an option for Least operational overhead, as the streams product requires some building of apps etc.
Comment: Option B is correct answer.
Comment: This solution meets the requirements as follows: • Kinesis Data Firehose can scale to ingest and process multiple terabytes per hour of streaming data. This can easily handle the petabyte-scale data volumes. • Firehose can deliver the data to Redshift, a petabyte-scale data warehouse, enabling on-demand SQL analytics of the data. • Redshift is a fully managed service, minimizing operational overhead. Firehose is also fully managed, handling scalability, availability, and durability of the streaming data ingestion.
Comment: B: The answer is certainly option "B" because ingesting user activity data can easily be handled by Amazon Kinesis Data streams. The ingested data can then be sent into Redshift for Analytics. Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. Amazon Redshift Serverless lets you access and analyze data without all of the configurations of a provisioned data warehouse. https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html
Comment: the Key sentence here is: "that facilitates on-demand analytics", tthats the reason because we need to choose Kinesis Data streams over Data Firehose
Comment: Why that? Analytics is done in Redshift, not by Kinesis.
Comment: B: Kinesis Data Firehose service automatically load the data into Amazon Redshift and is a petabyte-scale data warehouse service. It allows you to perform on-demand analytics with minimal operational overhead. Since the requirement didn't state what kind of analytics you need to run, we can assume that we do not need to set up additional services to provide further analytics. Thus, it has the least operational overhead. Why not A: It is a viable solution, but storing the data in S3 would require you to set up additional services like Amazon Redshift or Amazon Athena to perform the analytics.
Comment: A, E is the correct answer "RESTful web services" => API Gateway. "EC2 instance receives the raw data, transforms the raw data, and stores all the data in an Amazon S3 bucket" => GLUE with (Extract - Transform - Load)
Comment: AE breaks the original workflow "receive raw data - process - store" to "receive - store- process - store again" which leads to additional storage consuming (and thus money consuming).
Comment: A - Use AWS Glue to process the raw data in Amazon S3 E - Use Amazon API Gateway to send the raw data to an Amazon Kinesis data stream. Configure Amazon Kinesis Data Firehose to use the data stream as a source to deliver the data to Amazon S3
Comment: E then A no doubt.
Comment: A. It automatically discovers the schema of the data and generates ETL code to transform it. E. API Gateway can be used to receive the raw data from the remote devices via RESTful web services. It provides a scalable and managed infrastructure to handle the incoming requests. The data can then be sent to an Amazon Kinesis data stream, which is a highly scalable and durable real-time data streaming service. From there, Amazon Kinesis Data Firehose can be configured to use the data stream as a source and deliver the transformed data to Amazon S3. This combination of services allows for the seamless ingestion and processing of data while minimizing operational overhead.
Comment: A - Use AWS Glue to process the raw data in Amazon S3 E - Use Amazon API Gateway to send the raw data to an Amazon Kinesis data stream. Configure Amazon Kinesis Data Firehose to use the data stream as a source to deliver the data to Amazon S3
Comment: Correct answer: D and E
Comment: A. It automatically discovers the schema of the data and generates ETL code to transform it. E. API Gateway can be used to receive the raw data from the remote devices via RESTful web services. It provides a scalable and managed infrastructure to handle the incoming requests. The data can then be sent to an Amazon Kinesis data stream, which is a highly scalable and durable real-time data streaming service. From there, Amazon Kinesis Data Firehose can be configured to use the data stream as a source and deliver the transformed data to Amazon S3. This combination of services allows for the seamless ingestion and processing of data while minimizing operational overhead. B. It does not directly address the need for scalable data processing and storage. It focuses on managing DNS and routing traffic to different endpoints. C. Adding more EC2 can lead to increased operational overhead in terms of managing and scaling the instances. D. Using SQS and EC2 for processing data introduces more complexity and operational overhead.
Comment: Why not BC?
Comment: Why it not CE? Add more EC2 instances to accommodate the increasing amount of incoming data?
Comment: EC2 is not server-less. they want to minimize overhead
Comment: minimizes operational overhead = Serverless Glue, Kinesis Datastream, S3 are serverless
Comment: facts!!
Comment: How about "C" to increase EC2 instances for the increased devices soon?
Comment: Glue and API
Comment: https://www.examtopics.com/discussions/amazon/view/83387-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: This is the most cost-effective option because: • Versioning has caused the number of objects to increase over time, even as current objects are deleted after 3 years. By deleting previous versions as well, this will clean up old object versions and reduce storage costs. • An S3 Lifecycle policy incurs no additional charges and requires no additional resources to configure and run. It is a native S3 tool for managing object lifecycles cost-effectively.
Comment: I did something similar recently : Lifecycle is triggered more or less each 24 hours, in my case it removed hundreds of gigabytes and millions of small files in one shot. Using another mechanism like a script would have taken days if not weeks.
Comment: This is the most cost-effective option because: • Versioning has caused the number of objects to increase over time, even as current objects are deleted after 3 years. By deleting previous versions as well, this will clean up old object versions and reduce storage costs. • An S3 Lifecycle policy incurs no additional charges and requires no additional resources to configure and run. It is a native S3 tool for managing object lifecycles cost-effectively.
Comment: Ensure to delete previous versions as well.
Comment: By configuring the S3 Lifecycle policy to delete previous versions as well as current versions, the older versions of the CloudTrail logs will be deleted. This ensures that objects older than 3 years are removed from the S3 bucket, reducing the object count and controlling storage costs. A. This option is not directly related to managing objects in the S3. It focuses on configuring the expiration of CloudTrail trails, which may not address the need to delete objects from the S3 bucket. C. While it is technically possible to create a Lambda to delete objects older than 3 years, this approach would introduce additional complexity and operational overhead. D. Changing the ownership of the objects in the S3 bucket does not directly address the need to delete objects older than 3 years. Ownership does not affect the deletion behavior of the objects.
Comment: I go for option B.
Comment: I don't think it's possible to configure an S3 lifecycle policy to delete all versions of an object, so B is wrong ... I think the question is improperly worded
Comment: • Versioning has caused the number of objects to increase over time, even as current objects are deleted after 3 years. By deleting previous versions as well, this will clean up old object versions and reduce storage costs. • An S3 Lifecycle policy incurs no additional charges and requires no additional resources to configure and run. It is a native S3 tool for managing object lifecycles cost-effectively.
Comment: This is the most cost-effective option because: • Versioning has caused the number of objects to increase over time, even as current objects are deleted after 3 years. By deleting previous versions as well, this will clean up old object versions and reduce storage costs. • An S3 Lifecycle policy incurs no additional charges and requires no additional resources to configure and run. It is a native S3 tool for managing object lifecycles cost-effectively.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html
Comment: A more cost-effective solution would be to configure the organization's centralized CloudTrail trail to expire objects after 3 years. This would ensure that all objects, including previous versions, are deleted after the specified retention period. Another option would be to create an AWS Lambda function to enumerate and delete objects from Amazon S3 that are older than 3 years, this would allow you to have more control over the deletion process and to write a custom logic that best fits your use case.
Comment: As long as versioning on the S3 bucket is enabled, any deletion, whether performed by CloudTrail or by your custom Lambda function, will simply add a new version with a deletion market but will not delete the previous version.
Comment: The question clearly says "An S3 Lifecycle policy is in place to delete current objects after 3 years". This implies that previous versions are not deleted, since this is a separate setting, and since logs are constantly changed, it would seem to make sense to delete previous versions so, so B. D is wrong, since the parent account (the management account) will already be the owner of all objects delivered to the S3 bucket, "All accounts in the organization can see MyOrganizationTrail in their list of trails, but member accounts cannot remove or modify the organization trail. Only the management account or delegated administrator account can change or delete the trail for the organization.", see https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html
Comment: B is the right answer. Ref: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html#:~:text=The%20CloudTrail%20trail,time%20has%20passed. Option A is wrong. No way to expire the cloudtrail logs
Comment: Configure the S3 Lifecycle policy to delete previous versions
Comment: B. Configure the S3 Lifecycle policy to delete previous versions as well as current versions.
Comment: B. Configure the S3 Lifecycle policy to delete previous versions as well as current versions.
Comment: B is correct answer
Comment: Ans: A https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html When you create an organization trail, a trail with the name that you give it is created in every AWS account that belongs to your organization. Users with CloudTrail permissions in member accounts can see this trail when they log into the AWS CloudTrail console from their AWS accounts, or when they run AWS CLI commands such as describe-trail. However, users in member accounts do not have sufficient permissions to delete the organization trail, turn logging on or off, change what types of events are logged, or otherwise change the organization trail in any way.
Comment: correction: Ans D is the answer. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html
Comment: You need to also use AWS RDS Proxy becuase lambda will increase parallel and it will cause connection error
Comment: //minimize the number of connections to the database and must ensure that data is not lost during periods of heavy traffic// I go for C
Comment: Decouple the API and the DB with Amazon Simple Queue Service (Amazon SQS) queue.
Comment: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-lambda-function-trigger.html SQS can invoke lambda indeed. Initially I picked D because I wasn't sure it was possible but , this article shows it is. It makes this question even more confusing for me as it is also possible to trigger lambda from SNS: https://docs.aws.amazon.com/sns/latest/dg/sns-lambda-as-subscriber.html I don't know which option between C and D makes more sense. I still have a preference for D as it seems less hacky than C.
Comment: Decouple the API and the DB with Amazon Simple Queue Service (Amazon SQS) queue.
Comment: C. Modify the API to write incoming data to an Amazon Simple Queue Service (Amazon SQS) queue. Use an AWS Lambda function that Amazon SQS invokes to write data from the queue to the database.
Comment: By leveraging SQS as a buffer and using an Lambda to process and write data from the queue to the database, the solution provides scalability, decoupling, and reliability while minimizing the number of connections to the database. This approach handles fluctuations in traffic and ensures data integrity during high-traffic periods. A. Increasing the size of the DB instance may provide more memory, but it does not address the issue of handling high write traffic efficiently and minimizing connections to the database. B. Modifying the DB instance to be a Multi-AZ instance and writing to all active instances can improve availability but does not address the issue of efficiently handling high write traffic and minimizing connections to the database. D. Using SNS and an Lambda can provide decoupling and scalability, but it is not suitable for handling heavy write traffic efficiently and minimizing connections to the database.
Comment: I think D, "Use an AWS Lambda function that Amazon SQS invokes to write data from the queue to the database" SQS can't invokes Lambda becouse SQS is pull.
Comment: "Invoke a Lambda function from an Amazon SQS trigger" https://docs.aws.amazon.com/lambda/latest/dg/example_serverless_SQS_Lambda_section.html
Comment: Why not B
Comment: a) You can't write to multiple instances at the same time b) If you could, it would probably not increase performance c) if it would increase performance then it would probably double performance, which might not be enough Decoupling is the way to go - let clients submit data via APIs, and write it asynchronously to the database. Don't let clients wait until data has been written.
Comment: C is in deed the correct answer for the use case
Comment: C is correct
Comment: Cis correct
Comment: C looks ok
Comment: why not D?
Comment: C is correct.
Comment: C. Modify the API to write incoming data to an Amazon Simple Queue Service (Amazon SQS) queue. Use an AWS Lambda function that Amazon SQS invokes to write data from the queue to the database. To minimize the number of connections to the database and ensure that data is not lost during periods of heavy traffic, the company should modify the API to write incoming data to an Amazon SQS queue. The use of a queue will act as a buffer between the API and the database, reducing the number of connections to the database. And the use of an AWS Lambda function invoked by SQS will provide a more flexible way of handling the data and processing it. This way, the function will process the data from the queue and insert it into the database in a more controlled way.
Comment: Did you use ChatGPT?
Comment: same question as you :D
Comment: Migrating the databases to Aurora Serverless provides automated scaling and replication capabilities. Aurora Serverless automatically scales the capacity based on the workload, allowing for seamless addition or removal of compute capacity as needed. It also offers improved performance, durability, and high availability without requiring manual management of replication and scaling. B. Incorrect because it suggests migrating to a different database engine, which may introduce compatibility issues and require significant code modifications. C. Incorrect because consolidating into a larger MySQL database on larger EC2 instances does not provide the desired scalability and automation. D. Incorrect because using EC2 Auto Scaling groups for the database tier still requires manual management of replication and scaling.
Comment: Migrate the databases to Amazon Aurora Serverless for Aurora MySQL
Comment: Aurora MySQL
Comment: Option A is right answer.
Comment: A is correct because aurora might be more expensive but its serverless and is much faster
Comment: A is porper https://aws.amazon.com/rds/aurora/serverless/
Comment: Aurora MySQL
Comment: https://www.examtopics.com/discussions/amazon/view/51509-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: See https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
Comment: fyi yall in most cases nat instances are a bad thing because their customer managed while nat gateways are AWS Managed. So in this case I already know to get rid of the nat instances the reason its c is because it wants high availability meaning different AZs
Comment: Highly available, fault tolerant and automatically scalable=> Autoscaling and Diffrent AZ
Comment: NAT instances are legacy technology. "If you're already using a NAT instance, we recommend that you replace it with a NAT gateway." Thus C. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
Comment: Highly available, fault tolerant, and automatically scalable = two NAT gateways in different Availability Zones
Comment: Remove the two NAT instances and replace them with two NAT gateways in different Availability Zones
Comment: This recommendation ensures high availability and fault tolerance by distributing the NAT gateways across multiple AZs. NAT gateways are managed AWS services that provide scalable and highly available outbound NAT functionality. By deploying NAT gateways in differentAZs, the company can achieve redundancy and avoid a single point of failure. This solution also provides automatic scaling to handle increasing traffic without manual intervention. Option A is incorrect because placing both NAT gateways in the same Availability Zone does not provide fault tolerance. Option B is incorrect because using Auto Scaling groups with Network Load Balancers is not the recommended approach for NAT instances. Option D is incorrect because Spot Instances are not suitable for critical infrastructure components like NAT instances.
Comment: HA: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html Scalability: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Comment: Could anybody teach me why the B cannot be correct answer? This solution also seems providing Scalability(Auto Scaling Group), High Availability(different AZ), and Fault Tolerance(NLB & AZ). I honestly think that C is not enough, because each NAT gateway can provide a few scalability, but the bandwidth limit is clearly explained in the document. The C exactly mentioned "two NAT gateways" so the number of NAT is fixed, which will reach its limit soon.
Comment: Option B proposes to use an Auto Scaling group with Network Load Balancers to continue using the existing two NAT instances. However, NAT instances do not support automatic failover without a script, unlike NAT gateways which provide this functionality. Additionally, using Network Load Balancers to balance traffic between NAT instances adds more complexity to the solution. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
Comment: Thx for your explanation!
Comment: C. If you have resources in multiple Availability Zones and they share one NAT gateway, and if the NAT gateway's Availability Zone is down, resources in the other Availability Zones lose internet access. To create an Availability Zone-independent architecture, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-basics
Comment: Replace NAT Instances with Gateway
Comment: Correct answer is C
Comment: A is correct. B will work but is not the most secure method, since it will allow everything in VPC A to talk to everything in VPC B and vice versa, not at all secure. A on the other hand will only allow the application (since you select it's IP address) to talk to the application server in VPC A - you are allowing only the required connectivity. See the link for this exact use case: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html
Comment: " allows all traffic from the public IP address" Nice bro niceee This is absolutely the most secure method at all. :)))
Comment: :)))))))))
Comment: he must be the security engineer lolol :D "Jaybee" - Please dont ever say that traffic over the public internet is secure :D
Comment: Both VPCs are in the "SAME AWS ACCOUNT" and the requirement specifies allowing traffic from the *PUBLIC IP of the APPLICATION SERVER*. In this case the traffic remains inside the AWS infrastructure or will it go through the public internet?
Comment: Answer A (not "the requirement") specifies "allowing traffic from the public IP", which is for sure NOT the "most secure" option.
Comment: B. Configure a VPC peering connection between VPC A and VPC B. The most secure solution is to configure a VPC peering connection between the two VPCs. This allows private communication between the application server and the database, without exposing resources to the public internet. Option A exposes the database to the public internet by allowing inbound traffic from a public IP address. Option C makes the database instance itself public, which is insecure. Option D adds complexity with a proxy that is not needed when a VPC peering connection can enable private communication between VPCs. So option B is the most secure while allowing the necessary connectivity between the application server and the database in the separate VPCs.
Comment: Well this is a tricky one!!! Are we going to assume that the database in VPC B is in private subnet? In that case configuring security group to allow the traffic coming from Elastic IP of VPC A will not work. And if we use peering, the resources that live in the same subnet as the EC2 instance in VPC A will have access to the database? So what would we say to this? Is moving traffic through the public AWS space is safer than allowing access to the DB to other resources in VPC A?..... I don't know what to think
Comment: When you establish peering relationships between VPCs across different AWS Regions, resources in the VPCs (for example, EC2 instances and Lambda functions) in different AWS Regions can communicate with each other using private IP addresses, without using a gateway, VPN connection, or network appliance. The traffic remains in the private IP space. All inter-Region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks. Inter-Region VPC peering provides a simple and cost-effective way to share resources between regions or replicate data for geographic redundancy.
Comment: Most secure = not leaving AWS network. VPC peering is the way.
Comment: VPC to VPC comms = VPC peering
Comment: B is correct : Setup VPC peering and connect Application from VPC A to connect with VPC B in private subnet so DB instace always secure with internet.
Comment: Am I missing something or simply A is wrong because, without VPC peering (or other inter-connection sharing mechanisms such as Transit Gateway or VPN), VPC A and VPC B cannot communicate each other?
Comment: can use vpc endpoints but no option use that
Comment: When you establish peering relationships between VPCs across different AWS Regions, resources in the VPCs (for example, EC2 instances and Lambda functions) in different AWS Regions can communicate with each other using private IP addresses, without using a gateway, VPN connection, or network appliance. The traffic remains in the private IP space. All inter-Region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks. Inter-Region VPC peering provides a simple and cost-effective way to share resources between regions or replicate data for geographic redundancy. https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Comment: With peering, we EC2 can communicate with RDS. RDS SG can have inbound from EC2 IP rather than VPC CIDR for more security
Comment: VPC peering uses AWS network.
Comment: By configuring a VPC peering connection between VPC A and VPC B, you can establish private and secure communication between the EC2 instance in VPC A and the database in VPC B. VPC peering allows traffic to flow between the two VPCs using private IP addresses, without the need for public IP addresses or exposing the database to the internet. Option A is not the best solution as it requires allowing all traffic from the public IP address of the application server, which can be less secure. Option C involves making the DB instance publicly accessible, which introduces security risks by exposing the database directly to the internet. Option D adds unnecessary complexity by launching an additional EC2 instance in VPC B and proxying all requests through it, which is not the most efficient and secure approach in this scenario.
Comment: I don't like A because the security group setting is wrong as it set up to allow all public IP addresses. If the security group setting is correct, then I will go for A I don't like B because it need to set up security group as well on top of peering. for exam purpose only, I will go with the least worst choice which is B
Comment: The keywords are: "access MOST securely", hence the option A meets these requirements.
Comment: Each VPC security group rule makes it possible for a specific source to access a DB instance in a VPC that is associated with that VPC security group. The source can be a range of addresses (for example, 203.0.113.0/24), or another VPC security group. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide
Comment: Most secure = VPC peering
Comment: I vote for option B.
Comment: By publishing VPC flow logs to CloudWatch Logs and creating metric filters to detect RDP or SSH access, the operations team can configure an CloudWatch metric alarm to notify them when the alarm is triggered. This will provide the desired notification when RDP or SSH access to an environment is established. Option A is incorrect because CloudWatch Application Insights is not designed for detecting RDP or SSH access. Option B is also incorrect because configuring an IAM instance profile with the AmazonSSMManagedInstanceCore policy does not directly address the requirement of notifying the operations team when RDP or SSH access occurs. Option D is wrong beacuse configuring an EventBridge rule to listen for EC2 Instance State-change Notification events and using an SNS topic as a target will notify the operations team about changes in the instance state, such as starting or stopping instances. However, it does not specifically detect or notify when RDP or SSH access is established, which is the requirement stated in the question.
Comment: https://aws.amazon.com/blogs/security/how-to-monitor-and-visualize-failed-ssh-access-attempts-to-amazon-ec2-linux-instances/
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html#flow-log-example-accepted-rejected Adding this to support that VPC flow logs can be used to cvapture Accepted or Rejected SSH and RDP traffic.
Comment: I don't think C would be an acceptable solution ... the request is to be notified WHEN a SSH and/or RDP connection is established so it requires real-time monitoring and that is something the C solution does not provide ... I would select A as a correct answer
Comment: See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instance-state-changes.html
Comment: C sounds complex, but is the only answer that can work. Not A - Application Insights has nothing to do with SSH/RDP access to the OS; also we need a notification, not an OpsItem Not B - Just attaching a role does not create a notification Not D - Establishing SSH/RDP access is not a "state change" that would trigger this
Comment: A bit clueless here. AWS-recommended approach involves the CloudWatch Logs Agent on each EC2 instance, but that is not involved in any of the answers. A: Sounds good at first read, but "CloudWatch Application Insights" cannot detect RDP or SSH access. B: Would allow RDP or SSH access via Systems Manager, but would NOT prevent access without Systems Manager; also we'd need to configure notifications in Systems Manager which is not mentioned here.
Comment: C: Could work but it seems overkill to capture VPC flow logs just to detect SSH and RDP traffic. Also it is not real-time, and it's unclear how and when exactly the state transitions and notifications will be triggered. At best you'd get notification few minutes AFTER (not "when") "access has been established". Still, is has most similarity with the recommended approach to detect failed connections: https://aws.amazon.com/tr/blogs/security/how-to-monitor-and-visualize-failed-ssh-access-attempts-to-amazon-ec2-linux-instances/ D: Won't work because establishment of a connection is not an instance state change.
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html#flow-log-example-accepted-rejected Adding this to support that VPC flow logs can be used to cvapture Accepted or Rejected SSH and RDP traffic.
Comment: Publish VPC flow logs to Amazon CloudWatch Logs. Create required metric filters. Create an Amazon CloudWatch metric alarm with a notification action for when the alarm is in the ALARM state
Comment: VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to the following locations: Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose. After you create a flow log, you can retrieve and view the flow log records in the log group, bucket, or delivery stream that you configured. Flow logs can help you with a number of tasks, such as: Diagnosing overly restrictive security group rules Monitoring the traffic that is reaching your instance Determining the direction of the traffic to and from the network interfaces Ref link: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html
Comment: seems like c: https://aws.amazon.com/tr/blogs/security/how-to-monitor-and-visualize-failed-ssh-access-attempts-to-amazon-ec2-linux-instances/
Comment: This link does not mention VPC flow logs at all.
Comment: D. Configure an Amazon EventBridge rule to listen for events of type EC2 Instance State-change Notification. Configure an Amazon Simple Notification Service (Amazon SNS) topic as a target. Subscribe the operations team to the topic. This setup allows the EventBridge rule to capture instance state change events, such as when RDP or SSH access is established. The rule can then send notifications to the specified SNS topic, which is subscribed by the operations team.
Comment: D is wrong. EC2 instance state change is only for pending, running etc. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instance-state-changes.html you can't have state change of ssh or rdp.
Comment: C: https://www.youtube.com/watch?v=KAe3Eju59OU
Comment: https://aws.amazon.com/blogs/security/how-to-monitor-and-visualize-failed-ssh-access-attempts-to-amazon-ec2-linux-instances/
Comment: A. Configuring Amazon CloudWatch Application Insights to create AWS Systems Manager OpsItems when RDP or SSH access is detected would be the most appropriate solution in this scenario. This would allow the operations team to be notified when RDP or SSH access has been established and provide them with the necessary information to take action if needed. Additionally, Amazon CloudWatch Application Insights would allow for monitoring and troubleshooting of the system in real-time.
Comment: EC2 Instance State-change Notifications are not the same as RDP or SSH established connection notifications. Use Amazon CloudWatch Logs to monitor SSH access to your Amazon EC2 Linux instances so that you can monitor rejected (or established) SSH connection requests and take action.
Comment: The Answer can be A or C depending on the requirement if it requires real-time notification. A: Allows the operations team to be notified in real-time when access is established, and also provides visibility into the access events through the OpsItems. C: The logs will need to be analyzed and metric filters applied to detect access, and then the alarm will trigger based on that analysis. This method could have a delay in providing notifications. Thus, not the best solution if real-time notification is required. Why not D: RDP or SSH access does not cause an EC2 instance to have a state change. The state change events that Amazon EventBridge can listen for include stopping, starting, and terminated instances, which do not apply to RDP or SSH access. But RDP or SSH connection to an EC2 instance does generate an event in the system, such as a log entry which can be used to notify the Operation team. Since its a log, you would require a service that monitors logs like CloudTrail, VPC Flow logs, or AWS Systems Manager Session Manager.
Comment: I completely agree with the logic here, but I'm thinking C, since I believe you will need to "Create required metric filters" in order to detect RDP or SSH access, and this is not specified in the question, see https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html
Comment: It's C fam. RDP or SSH connections won't change the state of the EC2 instance, so D doesn't make sense.
Comment: D. Configure an Amazon EventBridge rule to listen for events of type EC2 Instance State-change Notification. Configure an Amazon Simple Notification Service (Amazon SNS) topic as a target. Subscribe the operations team to the topic. EC2 instances sends events to the EventBridge when state change occurs, such as when a new RDP or SSH connection is established, you can use EventBridge to configure a rule that listens for these events and trigger an action, like sending an email or SMS, when the connection is detected. The operations team can be notified by subscribing to the Amazon Simple Notification Service (Amazon SNS) topic, which can be configured as the target of the EventBridge rule.
Comment: Are state changes pending: running stopping stopped shutting-down terminated https://aws.amazon.com/blogs/security/how-to-monitor-and-visualize-failed-ssh-access-attempts-to-amazon-ec2-linux-instances/
Comment: A. Setting a strong password for the root user is an essential security measure to prevent unauthorized access. B. Enabling MFA adds an extra layer of security by requiring an additional authentication factor, such as a code from a mobile app or a hardware token, in addition to the password. C. Root user access keys should be avoided whenever possible, and it is best to use IAM users with restricted permissions instead. D. The root user already has unrestricted access to all resources and services in the account, so granting additional administrative permissions could increase the risk of unauthorized actions. E. Instead, it is recommended to create IAM users with appropriate permissions and use those users for day-to-day operations, while keeping the root user secured and only using it for necessary administrative tasks.
Comment: Ensure the root user uses a strong password. Enable multi-factor authentication to the root user.
Comment: Ensure the root user uses a strong password. Enable multi-factor authentication to the root user.
Comment: Options A & B are the CORRECT answers.
Comment: Options A & B are the right answers.
Comment: See https://docs.aws.amazon.com/SetUp/latest/UserGuide/best-practices-root-user.html
Comment: A and B are the correct answers: Option A: A strong password is always required for any AWS account you create, and should not be shared or stored anywhere as there is always a risk. Option B: This is following AWS best practice, by enabling MFA on your root user which provides another layer of security on the account and unauthorised access will be denied if the user does not have the correct password and MFA.
Comment: AB are the right answers.
Comment: This is probably the hardest question in AWS history
Comment: AB is the only feasible answer here.
Comment: B. Enabling multi-factor authentication for the root user provides an additional layer of security to ensure that only authorized individuals are able to access the root user account. E. Applying the required permissions to the root user with an inline policy document ensures that the root user only has the necessary permissions to perform the necessary tasks, and not any unnecessary permissions that could potentially be misused.
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
Comment: The other options are not sufficient to secure the root user access because: A. A strong password alone is not enough to protect against potential security threats such as phishing or brute force attacks. C. Storing the root user access keys in an encrypted S3 bucket does not address the root user's authentication process. D. Adding the root user to a group with administrative permissions does not address the root user's authentication process and does not provide an additional layer of security.
Comment: Strong passwords + multi factor is the counter to brute force...
Comment: E is wrong because you can't attach permissions or policies to the root user. A is right because MFA alone won't help too much if the password is "123".
Comment: AB obviusly
Comment: Root user already has admin, so D is not correct
Comment: AB are correct
Comment: D is incorrect as root user already has full admin access.
Comment: D. Add the root user to a group containing administrative permissions. >>its not about security,actually its unsecure so >> a&B
Comment: BD is correct
Comment: D is wrong because the root user is outside of IAM, thus you can't put him into a group. Also he does not need "administrative permissions" as he has those anyway.
Comment: root user is literally the super admin account. What more permissions could you possible give to the root user by adding it to admin group?
Comment: AWS KMS can be used to encrypt the EBS and Aurora database storage at rest. ACM can be used to obtain an SSL/TLS certificate and attach it to the ALB. This encrypts the data in transit between the clients and the ALB. A is incorrect because it suggests using ACM to encrypt the EBS, which is not the correct service for encrypting EBS. B is incorrect because relying on the AWS root account and selecting an option in the AWS Management Console to enable encryption for all data at rest and in transit is not a valid approach. D is incorrect because BitLocker is not a suitable solution for encrypting data in AWS services. It is primarily used for encrypting data on Windows-based operating systems. Additionally, importing TLS certificate keys to AWS KMS and attaching them to the ALB is not the recommended approach for encrypting data in transit.
Comment: Got this question in exam today
Comment: To encrypt data at rest, AWS Key Management Service (AWS KMS) can be used to encrypt EBS volumes and Aurora database storage. To encrypt data in transit, an AWS Certificate Manager (ACM) certificate can be attached to the Application Load Balancer (ALB) to enable HTTPS and TLS encryption.
Comment: Use AWS Key Management Service (AWS KMS) to encrypt the EBS volumes and Aurora database storage at rest. Attach an AWS Certificate Manager (ACM) certificate to the ALB to encrypt data in transit
Comment: C is the best answer. To encrypt data at rest, AWS Key Management Service (AWS KMS) can be used to encrypt EBS volumes and Aurora database storage. To encrypt data in transit, an AWS Certificate Manager (ACM) certificate can be attached to the Application Load Balancer (ALB) to enable HTTPS and TLS encryption.
Comment: Option C it's correct
Comment: Option C fulfills the requirements.
Comment: C is correct ,A REVERSES the work ofeach service.
Comment: C is correct!
Comment: c is correct answer
Comment: C : because we need SCT to convert from Oracle to PostgreSQL, and we need memory optimized machine for databases not compute optimized.
Comment: why it is memory optimized and not compute optimized machine ?
Comment: Maybe it doesn't matter, but in D we create a table mapping only for "the largest tables" while obviously we need "all tables" as in C.
Comment: A memory-optimized replication instance is recommended because the database has a high number of reads and writes. Memory-optimized instances are designed to deliver fast performance for workloads that process large data sets in memory.
Comment: thank you
Comment: B. Use AWS DataSync for the initial migration. Use AWS Database Migration Service (AWS DMS) to create a full load plus change data capture (CDC) replication task and a table mapping to select all tables. This approach leverages AWS DataSync for the initial data migration, which is optimized for high-speed transfer of large amounts of data. Then, AWS DMS is used to create a replication task with full load plus change data capture (CDC), ensuring ongoing synchronization between the on-premises Oracle database and Amazon Aurora PostgreSQL. By selecting all tables, the migration process ensures that all applications can continue to read from and write to the database without interruption during the migration period.
Comment: Answer is C - AWS Schema Conversion Tool (AWS SCT) supports heterogeneous database migrations by automatically converting the source database schema and a majority of the custom code to a format compatible with the target database.
Comment: Has to be SCT + DMS for all the tables so C is the choice. Why do you need SCT? Read this: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-data-from-an-on-premises-oracle-database-to-aurora-postgresql.html
Comment: AB-> DataSync has nothing to do with DB Migration (https://aws.amazon.com/datasync/) D: Only migrates the largest table I think these questions are more for seeing how much of AWS product catalogue can you remember efficiently with associated features. Afterall AWS SA is also a salesperson for the right product! I now look at product cheat-sheets to look them up at work.
Comment: Oracle -> PostgreSQL, we need SCT, thus A and B are out. D maps only "the largest tables" but we need all tables
Comment: Another reason to rule out D is because it states “a table mapping to select the largest tables”, whereas selecting all tables (as stated in option C) in the table mapping is necessary to ensure a comprehensive migration.
Comment: because we need SCT to convert from Oracle to PostgreSQL, and we need memory optimized machine for databases not compute optimized. A memory-optimized replication instance is recommended because the database has a high number of reads and writes. Memory-optimized instances are designed to deliver fast performance for workloads that process large data sets in memory.
Comment: because we need SCT to convert from Oracle to PostgreSQL, and we need memory optimized machine for databases not compute optimized. https://repost.aws/zh-Hant/knowledge-center/dms-optimize-aws-sct-performance
Comment: Oracle database to Amazon Aurora PostgreSQL = AWS Schema Conversion Tool High number of reads and writes = memory optimized replication instance
Comment: A memory-optimized replication instance is recommended because the database has a high number of reads and writes. Memory-optimized instances are designed to deliver fast performance for workloads that process large data sets in memory.
Comment: DataSync is for file-level synch, so A and B can be excluded. C is better than D because memory-optimized instances are recommended to handle the high number of reads and writes
Comment: why not a? only capture the change is sufficient
Comment: Oracle -> PostgreSQL requires SCT
Comment: Bbbbbb
Comment: The AWS SCT is used to convert the schema and code of the Oracle database to be compatible with Aurora PostgreSQL. AWS DMS is utilized to migrate the data from the Oracle database to Aurora PostgreSQL. Using a memory-optimized replication instance is recommended to handle the high number of reads and writes during the migration process. By creating a full load plus CDC replication task, the initial data migration is performed, and ongoing changes in the Oracle database are continuously captured and applied to the Aurora PostgreSQL database. Selecting all tables for table mapping ensures that all the applications writing to the same tables are migrated. Option A & B are incorrect because using AWS DataSync alone is not sufficient for database migration and data synchronization. Option D is incorrect because using a compute optimized replication instance is not the most suitable choice for handling the high number of reads and writes.
Comment: BBBBBBBBBBBBB
Comment: B chatgpt
Comment: DMS+SCT for Oracle to Aurora PostgreSQL migration https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-oracle-database-to-aurora-postgresql-using-aws-dms-and-aws-sct.html
Comment: B and D very similar with D being the 'best' solution but it is not the one that requires the least amount of development changes as the application would need to be changed to store images in S3 instead of DB
Comment: B is wrong because single "RDS DB instance" is not HA. No one says that the images are currently stored in S3. Also the requirement is "least amount of change [not "no change"] to the application".
Comment: for "Highly available": Multi-AZ & for "least amount of changes to the application": Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring
Comment: A: Requires changing EC2 application to Lambda. Seems like a big change B: RDS DB is not best option for serve images and also single instance isn't HA C: Memory optimised instance is not HA D: Multi-AZ EBS is lift and shift for EC2 front-end and app later. RDS Multi AZ is HA. S3 for static images is best performance/scalability/availability.
Comment: Using Amazon RDS for serving images might not be the optimal solution, as RDS is more suitable for storing structured data in a relational database rather than BLOBs like images. Storing and serving images can be more efficiently handled by object storage services like Amazon S3.
Comment: Use load-balanced Multi-AZ AWS Elastic Beanstalk environments for the front-end layer and the application layer. Move the database to an Amazon RDS Multi-AZ DB instance. Use Amazon S3 to store and serve users' images
Comment: Option B - DB is not a good option to store images. Read replicas won't improve HA for write, only scalates reading IO. Therefore no true HA achieved. D is the goal for me.
Comment: Use load-balanced Multi-AZ AWS Elastic Beanstalk environments for the front-end layer and the application layer. Move the database to an Amazon RDS Multi-AZ DB instance. Use Amazon S3 to store and serve users' images
Comment: Use Elastic Beanstalk load-balanced environments for the web and app tiers. This provides auto scaling and high availability with minimal effort. Move the database to RDS Multi-AZ. This handles scaling reads and storage, and provides HA with automated failover. Use S3 for serving user images. S3 is highly scalable and durable storage. The application code remains unchanged using this approach.
Comment: AWS Elastic Beanstalk makes it even easier for developers to quickly deploy and manage applications in the AWS Cloud. Developers simply upload their application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. I don't quite understand why people choose D.
Comment: By using load-balanced Multi-AZ AWS EBS, you achieve scalability and high availability for both layers without requiring significant changes to the application. Moving the DB to an RDS Multi-AZ DB ensures high availability and automatic failover. Storing and serving users' images through S3 provides a scalable and highly available solution. A is incorrect because using S3 for the front-end layer and Lambda for the application layer would require significant changes to the application architecture. Moving the DB to DynamoDB would require rewriting the DB-related code. B is incorrect because using load-balanced Multi-AZ AWS EBS environments and an RDS DB with read replicas for serving images would be a more suitable solution. RDS with read replicas can handle the image-serving workload more efficiently than using S3 for this purpose. C is incorrect because using S3 for the front-end layer and an ASG of EC2 for the application layer would require modifying the application architecture. Storing and serving images from a memory-optimized EC2 type may not be the most efficient and scalable approach compared to using S3.
Comment: "least amount of change to the application." - A has lots of changes, completely revamping the application and lots of new pieces. D is closest with only addition of s3 to store images which is right move. You do not want images to store in any database anyway.
Comment: Thats what I was thinking, but the question doesn't mention anything about storing users' images anywhere. Are we supposed to just assume that they wanted to store the images in a DB even though that is a bad idea?
Comment: Option D meets the requirements.
Comment: D is correct
Comment: RDS multi AZ.
Comment: D is correct as application changes needs to me minimal
Comment: Correct answer is D
Comment: https://www.examtopics.com/discussions/amazon/view/24840-exam-aws-certified-solutions-architect-associate-saa-c02/ Please ExamTopics, review your own answers
Comment: AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck. https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Comment: A VPC peering connection allows secure communication between instances in different VPCs using private IP addresses without the need for internet gateways, VPN connections, or NAT devices. By setting it up, the application running in VPC-A can directly access the EC2 in VPC-B without going through the public internet or any single point of failure. B is incorrect because VPC gateway endpoints are used for accessing S3 or DynamoDB from a VPC without going over the internet. They are not designed for establishing connectivity between EC2 instances in different VPCs. C is incorrect because it would require configuring a VPN connection between the VPCs. This would introduce additional complexity and potential single points of failure. D is incorrect because creating a private VIF and adding routes would be applicable for establishing a direct connection between on-premises infrastructure and VPC-B using Direct Connect, but it is not suitable for the scenario of communication between EC2 instances in separate VPCs within different AWS accounts.
Comment: You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account. Peering within the same AZ is free of charge.
Comment: I get a little confused about B and A but, because, with a VPC endpoint in B it will work too access from A.
Comment: vpc gw endpoint just dynamo and s3
Comment: B is wrong because "VPC gateway endpoint" is for S3 or DynamoDB, not EC2 C is overkill, would require a second gateway in VPC-A, not be HA and have limited bandwidth D is wrong because VIF is for Direct Connect, has nothing to do with VPC-to-VPC communication
Comment: AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck. https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Comment: A. Set up a VPC peering connection between VPC-A and VPC-B
Comment: https://www.bing.com/search?pglt=41&q=can+we+do+VPC+peering+across+AWS+accounts&cvid=48a8ceecc85a429c9ddd698b01055890&aqs=edge..69i57j0l8j69i11004.10897j0j1&FORM=ANNAB1&PC=LCTS
Comment: D, VPC PEERINGVIS IN SAME ACCOUNT
Comment: No, VPC Peering can use across account. https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Comment: DDDDDDDDDDDDDD
Comment: This is the only viable solution Create a private virtual interface (VIF) for the EC2 instance running in VPC-B and add appropriate routes from VPC-A
Comment: "You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account." https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Comment: correct answer is A and as mentioned by JayBee65 below, key reason being that solution should not have a single point of failure and bandwidth restrictions the following paragraph is taken from the AWS docs page linked below that backs this up "AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck." https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
Comment: A VPC endpoint gateway to the EC2 Instance is more specific and more secure than forming a VPC peering that exposes the whole of the VPC infrastructure just for one connection.
Comment: Your logic is correct but security is not a requirement here - the requirements are "The connectivity should not have a single point of failure or bandwidth concerns." A VPC gateway endpoint" would form a single point of failure, so B is incorrect, (and C and D are incorrect for the same reason, they create single points of failure).
Comment: B is about a Gateway endpoint, which can be used to connect to S3 or DynamoDB, NOT to another EC2 instance.
Comment: Correct answer is A
Comment: VPC peering allows resources in different VPCs to communicate with each other as if they were within the same network. This solution would establish a direct network route between VPC-A and VPC-B, eliminating the need for a single point of failure or bandwidth concerns.
Comment: https://www.examtopics.com/discussions/amazon/view/27763-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: AWS Budgets allows you to create budgets for your AWS accounts and set alerts when usage exceeds a certain threshold. By creating a budget for each account, specifying the period as monthly and the scope as EC2 instances, you can effectively track the EC2 usage for each account and be notified when a threshold is exceeded. This solution is the most cost-effective option as it does not require additional resources such as Amazon Athena or Amazon EventBridge.
Comment: AWS Budgets allows you to create budgets for your AWS accounts and set alerts when usage exceeds a certain threshold. By creating a budget for each account, specifying the period as monthly and the scope as EC2 instances, you can effectively track the EC2 usage for each account and be notified when a threshold is exceeded. This solution is the most cost-effective option as it does not require additional resources such as Amazon Athena or Amazon EventBridge.
Comment: Option A and Option B suggest using Cost Explorer to create reports and send notifications. While Cost Explorer is useful for analyzing costs, it does not provide the real-time alerting capability that AWS Budgets offers. Option D suggests using AWS Cost and Usage Reports integrated with Amazon Athena and Amazon EventBridge, which can be a more complex and potentially costlier solution compared to AWS Budgets for this specific use case. It's also more suitable for fine-grained, custom analytics rather than straightforward threshold-based alerts.
Comment: AWS Budgets was designed to handle this scenario.
Comment: Use AWS Budgets to create a cost budget for each account. Set the period to monthly. Set the scope to EC2 instances. Set an alert threshold for the budget. Configure an Amazon Simple Notification Service (Amazon SNS) topic to receive a notification when a threshold is exceeded.
Comment: By creating a cost budget for each account, specifying the period as monthly and scoping it to EC2, you can track and monitor the costs associated with EC2 specifically. Set an alert threshold in the budget, which will trigger a notification when the specified threshold is exceeded. Configure an SNS to receive the notification, which can be subscribed to by the company to receive immediate alerts. A and B are not the most cost-effective solutions as they involve using Cost Explorer to create reports, which may not provide real-time notifications when the threshold is exceeded. Additionally, A. suggests using a daily report, while B. suggests using a monthly report, which may not provide the desired level of granularity for immediate notifications. D involves using Cost and Usage Reports with Athena and EventBridge. This solution provides more flexibility and data analysis capabilities, it is more complex and may incur additional costs for using Athena and generating hourly reports.
Comment: I go with D. It says "as soon as", "daily" reports seems to be a bit longer time frame to wait in my opinion.
Comment: Actually, I take that back. It clearly says "Cost effective."
Comment: Athena can only be use in s3, that is enough to discard D
Comment: C: AWS Budgets allows you to set a budget for costs and usage for your accounts and you can set alerts when the budget threshold is exceeded in real-time which meets the requirement. Why not B: B would be the most cost-effective if the requirements didn't ask for real-time notification. You would not incur additional costs for the daily or monthly reports and the notifications. But doesn't provide real-time alerts.
Comment: Agree...C
Comment: Answer is C
Comment: https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/
Comment: AWS budget IMO, it's done for it
Comment: A. Create an Amazon API Gateway REST API. Configure the method to use the Lambda function. Enable IAM authentication on the API. This option is the most operationally efficient as it allows you to use API Gateway to handle the HTTPS endpoint and also allows you to use IAM to authenticate the calls to the microservice. API Gateway also provides many additional features such as caching, throttling, and monitoring, which can be useful for a microservice.
Comment: The question specifically asks for the solution that is most operationally efficient, not necessarily the one with the most features (which is A). Option B—using a Lambda function URL with AWS_IAM authentication—is indeed the most operationally efficient because: 1) Minimal Configuration: Lambda function URLs are designed to quickly create HTTPS endpoints without the need for additional AWS services like API Gateway. 2) Built-in IAM Authentication: You can easily specify AWS_IAM as the authentication type directly, fulfilling the requirement without extra setup. 3) No Extra Overhead: Unlike API Gateway, there's no need to manage complex API configurations, throttling settings, or additional API management features unless specifically required.
Comment: B is the most operationally efficient solution. It provides the necessary functionality with minimal setup and cost, directly supports IAM authentication, and avoids the additional complexity and overhead associated with other options. This approach is particularly suitable for scenarios where the API requirements are straightforward and do not need the advanced features provided by API Gateway or CloudFront.
Comment: I think from a decoupllng and separation of concerns A is the answer. You dont want to have a heavy reliance on the Lambda function with you have specific services for what is being required. there is operationally efficient incorrect and operationally efficient correct. So A is the best answer.
Comment: According to this statement "MOST operationally efficient way" and the following link related to Lambda Function URL security: https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html
Comment: I originally voted B but after reading this article, I am not sure if A is wrong or is just badly worded. If A actually said "Configure the [authorization] method to use the Lambda function" then it would be way more logical than B but this could be intentional. Although I think this is AWS test not IELTS so picking right answers based on small word mistakes is not the intention! https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html
Comment: A& B are all good. The requirement is most operationally efficient so B is faster. In real life, I won't risk B for production, dev & test makes sense but no production please
Comment: Reference link why B is here: https://aws.amazon.com/blogs/aws/announcing-aws-lambda-function-urls-built-in-https-endpoints-for-single-function-microservices/
Comment: I think this question has 2 answers as both A and B will work. However, B is more operationally efficient due to Lambda function URL and direct support for AWS_IAM as the auth type for this setup. https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html#urls-auth-iam C, D are not operationally efficient and GO is not supported on Lambda@Edge or CloudFront functions. Even if AWS start supporting it, the operational efficiency with increase because of CloudFront
Comment: * meant to say "operational efficiency will decrease" because of CloudFront
Comment: We know that the application provides "an HTTPS endpoint" but we don't even know whether it is a REST API. The question is not mentioning any other requirements besides IAM authentication, which can be handled by Lambda alone. A would work, but would be an additional processing step (lowering operational efficiency). It would also provide benefits but none of those is asked for in the question. C and D is wrong because Lambda@Edge does not support Go.
Comment: Options B, C, and D involve using Lambda function URLs or CloudFront, but they lack the full set of features provided by API Gateway, such as built-in IAM authentication, throttling, and other API management capabilities.
Comment: I think it is B - most operationally efficient. A is a better answer, but more complicated.
Comment: There is no need of an additional API gateway when Lambda itself can support the need. This is more operationally efficient.
Comment: Why not B? I agree that A is a nice choice, but it clearly says "MOST operationally efficient way", there is nothing said about API. B in this case suits absolutely fine, it's simpler and cheaper.
Comment: Create an Amazon API Gateway REST API. Configure the method to use the Lambda function. Enable IAM authentication on the API
Comment: A. Create an Amazon API Gateway REST API. Configure the method to use the Lambda function. Enable IAM authentication on the API. This option is the most operationally efficient as it allows you to use API Gateway to handle the HTTPS endpoint and also allows you to use IAM to authenticate the calls to the microservice. API Gateway also provides many additional features such as caching, throttling, and monitoring, which can be useful for a microservice.
Comment: C & D (incorrect) - what will be the origin for CDN? Plus Go is not supported. Plus for option D, IAM is not supported. A, why develop and manage API in API GW? Just enable Lambda function URL...
Comment: B -- MOST operationally efficient. Just look at the Lambda Create function console... Enable function URL > Use function URLs to assign HTTP(S) endpoints to your Lambda function. Auth type Choose the auth type for your function URL. > AWS_IAM Only authenticated IAM users and roles can make requests to your function URL.
Comment: A. --> No since if you access via internet you are creating egress traffic. B. -->It's a good choice to have both DWH and visualization in the same region to lower the egress transfer (i.e. data going egress/out of the region) but if you access over internet you might still have egress transfer. C. -> Valid but in this case you send out of AWS 50MB if you query the DWH instead of the visualization tool, D removes this need since puts the visualization tools in AWS with the DWH so reduces data returned out of AWS from 50MB to 500KB D. --> Correct, see explanation on answer C ------------------------------------------------------------------------------------------------------------------------------------------- Useful links: AWS Direct Connect connection create a connection in an AWS Direct Connect location to establish a network connection from your premises to an AWS Region. https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
Comment: It is not quite making sense that the answer D to mention on AWS Direct Connect if the tool is staying with AWS already. That is the main reason i vote on C rather than D.
Comment: I thought Direct Connect is exclusively for on-prem to VPC. Why would you use DirectConnect to connect to a service in your own Region in the AWS Cloud? I believe C is correct.
Comment: Agree with you 100%
Comment: This is question that need a careful reading of the question. Please note: in the question that the company has a DX connection but it doesn't mention the company is utilizing the DX to query the data warehouse (this indicates that the query was using internet). So my verdict would be to place the visualization tool on-prem (which it already is) and use the DX to query the data warehouse to reduce cost of (DTO) so I vote for C
Comment: The answer is C. At no point does the question suggest that the DWH source is out of Region.
Comment: It's D. Host the visualization on the same region to avoid egress cost and access the tool via AWS Direct connection.
Comment: Leverage the existing DirectConnect so not incur data transfer charge
Comment: D. Host the visualization tool in the same AWS Region as the data warehouse and access it over a Direct Connect connection at a location in the same Region.
Comment: Host the visualization tool in the same AWS Region as the data warehouse and access it over a Direct Connect connection at a location in the same Region
Comment: D. Host the visualization tool in the same AWS Region as the data warehouse and access it over a Direct Connect connection at a location in the same Region.
Comment: by hosting in same region, you have 500kb transfer charged on internet transfer teir, 50MB charged in inter-region tier. using direct link, both are charged in direct link tier. direct link tier is not cheap. so i go for B
Comment: We don't want "lowest cost", we want "lowest data transfer egress cost". And "data transfer egress" cost for Direct Connect is WAY lower than for Internet. (Therefor the circuit itself is expensive, but that does exist anyway.)
Comment: Aaaaaaaa
Comment: Hosting the visualization tool in the same AWS Region as the data warehouse and accessing it over a Direct Connect connection within the same Region eliminates data transfer fees and ensures low-latency, high-bandwidth connectivity. A. Hosting the visualization tool on premises and querying the data warehouse over the internet incurs data transfer costs for every query result, as well as potential latency and bandwidth limitations. B. Hosting the visualization tool in the same AWS Region as the data warehouse but accessing it over the internet still incurs data transfer costs for each query result. C. Hosting the visualization tool on premises and querying the data warehouse over a Direct Connect connection within the same AWS Region incurs data transfer costs for every query result and adds complexity by requiring on-premises infrastructure.
Comment: D let you reduce at minimum the data transfer costs
Comment: D: Direct Connect connection at a location in the same Region will provide the lowest data transfer egress cost, improved performance, and lower complexity Why it is not C is because the visualization tool is hosted on-premises, as it's not hosted in the same region as the data warehouse the data transfer between them would occur over the internet, thus, would incur in egress data transfer costs.
Comment: C option doesnt travel through internet because we have a direct connect. If you are hosting your visualization tool in same region why you need a direct connection which D has? Doesn't make sense. So, C is the right answer.
Comment: https://www.nops.io/reduce-aws-data-transfer-costs-dont-get-stung-by-hefty-egress-fees/
Comment: Whilst "Direct Connect can help lower egress costs even after taking the installation costs into account. This is because AWS charges lower transfer rates." D removes the need to send the query results out of AWS and instead returns the web page, so reduces data returned from 50MB to 500KB, so D
Comment: Correct answer is D
Comment: Should be D https://aws.amazon.com/directconnect/pricing/ https://aws.amazon.com/blogs/aws/aws-data-transfer-prices-reduced/
Comment: https://www.examtopics.com/discussions/amazon/view/47140-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Multi az is not the same as multi regional
Comment: B: Amazon RDS Multi-AZ feature automatically creates a synchronous replica in another availability zone and failover to the replica in the event of an outage. This will provide high availability and data durability across multiple AWS regions which fit the requirements. Though C may sound good, it in fact requires manual management and monitoring of the replication process due to the fact that Amazon RDS read replicas are asynchronous, meaning there is a delay between the primary and read replica. Therefore, there will be a need to ensure that the read replica is constantly up-to-date and someone still has to fix any read replica errors during the replication process which may cause data inconsistency. Lastly, you still have to configure additional steps to make it fail over to the read replica.
Comment: I go with option B because: Multi-AZ is for high availiblity Read replicas are for low-latency in question they talk about available online
Comment: They also ask for multiple regions which is not covered by Multi AZ
Comment: But the question is clearly asking for Multiple Regions. Multi-AZ is not across Regions.
Comment: You are right, Multi-AZ is only within one Region. C would be the right answer.
Comment: https://aws.amazon.com/rds/features/multi-az/ smartegnine 0 minutes ago Awaiting moderator approval Selected Answer: B In an Amazon RDS Multi-AZ deployment, Amazon RDS automatically creates a primary database (DB) instance and synchronously replicates the data to an instance in a different AZ.
Comment: Multi AZ is not supported in to diffrent region read Raplica is supported in to diffrent region So I am go with the option C
Comment: Option C involves setting up read replicas in another region, which provides cross-region availability but may introduce additional complexity in managing replication and monitoring. B. Migrate the PostgreSQL database to an Amazon RDS for PostgreSQL DB instance with Multi-AZ: High Availability: Amazon RDS Multi-AZ deployments provide high availability and failover support for DB instances. With Multi-AZ, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone (AZ). In the event of a failure, Amazon RDS automatically fails over to the standby replica, ensuring data availability and minimal downtime. + Cross-Region Replication.
Comment: A - Just no B - Multi-AZ is multiple AZs in same region, does not meet "Multiple AWS Regions" requirement C - Meets requirements D - Does not meet the "online ... at all times" requirement
Comment: Multi az is not the same as multi regional
Comment: Option C, while providing a read replica in another Region, adds complexity to the architecture and may introduce some additional operational overhead compared to Multi-AZ. Cross-Region replication involves setting up and managing replication between two separate RDS instances.
Comment: But data must be online "across multiple AWS regions"!
Comment: Migrate the PostgreSQL database to an Amazon RDS for PostgreSQL DB instance. Create a read replica in another Region
Comment: Multi-AZ is not the same as Multi-Regional
Comment: can someone explain why not D
Comment: "Data must be online (!) across multiple AWS regions at all times (!)". Snapshots are not online.
Comment: key words "AWS Regions at all times" so C is correct
Comment: key words "AWS Regions at all times"
Comment: By migrating the PostgreSQL database to an RDS for PostgreSQL DB instance and creating a read replica in another AWS Region, you can achieve data availability and online access across multiple Regions. This solution requires less operational overhead compared to managing a PostgreSQL cluster on EC2 instances (Option A) or setting up manual replication using snapshots (Option D). Additionally, Amazon RDS handles the underlying infrastructure and replication setup, reducing the operational complexity for the company. Option B, is a valid solution for achieving high availability within a single AWS Region. However, it does not meet the requirement of having the data available and online across multiple AWS Regions at all times, which is specified in the question. The Multi-AZ feature in RDS provides automatic failover within the same Region, but it does not replicate the data to multiple Regions.
Comment: C and D just specifiy another single region. This does not translate to multiple regions. B (Multi-AZ) means the solution will be highly available. The data will be available in multiple regions for both B and C but B is a better solution!
Comment: its data is available and online across multiple AWS Regions at all times
Comment: "Another single region" plus the original region ARE of course "multiple regions", what else? While B "Multi-AZ" is two AZs in the same region.
Comment: Answer B is not right, because "RDS Multi-AZ" always span at least two Availability Zones within a single region and the question requirment RDS DB should be available in multiple regions. Therefore, C is the most suitable answer for this question.
Comment: I would like to change my answer to "B". The question has some distractor words: "its data is available and online across multiple AWS Regions at all times". We agree that AWS is a could service available online around the world in 99 regions. So the option "B" is the most appropriate answer, since multi-AZ focuses on the avialability factor and it has the LEAST amount of operational overhead.
Comment: B & C both makes data available. However, B is less overhead. What I think, the question is asking for data availability across multiple regions not for a DR solution. So, RDS being accessible over public IP will do the trick for data being available across regions.
Comment: Multi-AZ is not the same as Multi-Regional
Comment: Option meets the requirements, ref. link: https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-for-postgresql-cross-region-read-replicas/
Comment: Use a multivalue answer routing policy to help distribute DNS responses across multiple resources. For example, use multivalue answer routing when you want to associate your routing records with a Route 53 health check. For example, use multivalue answer routing when you need to return multiple values for a DNS query and route traffic to multiple IP addresses. https://aws.amazon.com/premiumsupport/knowledge-center/multivalue-versus-simple-policies/
Comment: The Multivalue routing policy allows Route 53 to respond to DNS queries with multiple healthy IP addresses for the same resource. This is particularly useful in scenarios where multiple instances are serving the same purpose and need to be load balanced or failover capable. With the Multivalue routing policy, Route 53 returns multiple IP addresses in a random order to distribute the traffic across all healthy instances. Option A (Simple routing policy) would only return a single IP address in response to DNS queries and does not support returning multiple addresses. Option B (Latency routing policy) is used to route traffic based on the lowest latency to the resource and does not fulfill the requirement of returning all healthy IP addresses. Option D (Geolocation routing policy) is used to route traffic based on the geographic location of the user and does not fulfill the requirement of returning all healthy IP addresses. Therefore, the Multivalue routing policy is the most suitable option for returning the IP addresses of all healthy EC2 instances in response to DNS queries.
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-multivalue "Multivalue answer routing policy – Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random. You can use multivalue answer routing to create records in a private hosted zone." Company requires that the IP addresses of "ALL" healthy EC2 instances be returned so C is the only option.
Comment: Use a multivalue answer routing policy to help distribute DNS responses across multiple resources. For example, use multivalue answer routing when you want to associate your routing records with a Route 53 health check. For example, use multivalue answer routing when you need to return multiple values for a DNS query and route traffic to multiple IP addresses.
Comment: Use Multivalue answer routing policy when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random.
Comment: C. Multivalue routing policy
Comment: A. Deploy an AWS Storage Gateway file gateway as a virtual machine (VM) on premises at each clinic
Comment: This is for a different question I guess
Comment: multivalue supports health checks
Comment: IP are returned RANDOMLY for multi-value Routing, is this what we want ?
Comment: Multivalue answer routing policy ...answer is C
Comment: Answer is C
Comment: Should be C
Comment: https://www.examtopics.com/discussions/amazon/view/46491-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: https://www.examtopics.com/discussions/amazon/view/46491-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A. Deploy an AWS Storage Gateway file gateway as a virtual machine (VM) on premises at each clinic AWS Storage Gateway is a service that connects an on-premises software appliance with cloud-based storage to provide seamless and secure integration between an organization's on-premises IT environment and AWS's storage infrastructure. By deploying a file gateway as a virtual machine on each clinic's premises, the medical research lab can provide low-latency access to the data stored in the S3 bucket while maintaining read-only permissions for each clinic. This solution allows the clinics to access the data files directly from their on-premises file-based applications without the need for data transfer or migration.
Comment: A. It allows the clinics to access the data files stored in the S3 bucket through a file interface. The file gateway caches frequently accessed data locally, reducing latency and providing fast access to the data. B. It involves transferring the data files from the Amazon S3 bucket to each clinic's on-premises applications using AWS DataSync. While this enables data migration, it may not provide real-time access and may introduce additional latency. C. It is suitable for block-level access to data rather than file-level access. It may not be the most efficient solution for file-based applications. D. It involves using Amazon EFS, which is a scalable file storage service, to provide file-level access to the data. However, it may introduce additional complexity and latency compared to using a file gateway solution.
Comment: A: does exactly that is required here B: "Migrate", as to MOVE the files out from S3, doesn't make sense C: Volume Gateway provides iSCSI volumes backed by an object in AWS-managed S3, it does not provide access to S3 objects D: You can do that but it would have high (not "minimum") latency, and the data is not in that EFS volume, it's in S3
Comment: AWS Storage Gateway is a service that connects an on-premises software appliance with cloud-based storage to provide seamless and secure integration between an organization's on-premises IT environment and AWS's storage infrastructure. By deploying a file gateway as a virtual machine on each clinic's premises, the medical research lab can provide low-latency access to the data stored in the S3 bucket while maintaining read-only permissions for each clinic. This solution allows the clinics to access the data files directly from their on-premises file-based applications without the need for data transfer or migration.
Comment: The Amazon S3 File Gateway enables you to store and retrieve objects in Amazon Simple Storage Service (S3) using file protocols such as Network File System (NFS) and Server Message Block (SMB). Objects written through S3 File Gateway can be directly accessed in S3.
Comment: A. Deploy an AWS Storage Gateway file gateway as a virtual machine (VM) on premises at each clinic
Comment: Option A meets the requirements.
Comment: For File-based applications use File Gateway: (Option A)
Comment: Definitely A. Why are there so many wrong answers by Admins?
Comment: I guess to force us to read and think, so one can't just memorize the answer and go to exam ?)
Comment: Amazon S3 File Gateway enables you to store file data as objects in Amazon S3 cloud storage for data lakes, backups, and Machine Learning workflows. With Amazon S3 File Gateway, each file is stored as an object in Amazon S3 with a one-to-one mapping between a file and an object. Volume Gateway provides block storage volumes over iSCSI, backed by Amazon S3, and provides point-in-time backups as Amazon EBS snapshots. Volume Gateway integrates with AWS Backup, an automated and centralized backup service, to protect Storage Gateway volumes. So it's A
Comment: A for answer
Comment: https://cloud.in28minutes.com/aws-certification-aws-storage-gateway
Comment: A. Deploy an AWS Storage Gateway file gateway...
Comment: The correct answer is A. https://www.knowledgehut.com/tutorials/aws/aws-storage-gateway#:~:text=AWS%20Storage%20Gateway%20helps%20in%20connecting,as%20well%20as%20providing%20data%20security.&text=AWS%20Storage%20Gateway%20helps,as%20providing%20data%20security.&text=Gateway%20helps%20in%20connecting,as%20well%20as%20providing https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html
Comment: I think C (Volume Gateway) is correct as it has an option to have Local Storage with Asynchronous sync with S3. This would give low latency access to all local files not just cached/recent files.
Comment: Volume gateway provides an iSCSI volume and stores that as a single object in an AWS-managed S3 bucket. It does not provide access to S3 objects.
Comment: https://aws.amazon.com/storagegateway/file/
Comment: A. Deploy an AWS Storage Gateway file gateway as a virtual machine (VM) on premises at each clinic
Comment: C. Move the database to Amazon Aurora with a read replica in another Availability Zone. Create an Amazon Machine Image (AMI) from the EC2 instance. Configure an Application Load Balancer in two Availability Zones. Attach an Auto Scaling group that uses the AMI across two Availability Zones. This approach will provide both high availability and scalability for the website platform. By moving the database to Amazon Aurora with a read replica in another availability zone, it will provide a failover option for the database. The use of an Application Load Balancer and an Auto Scaling group across two availability zones allows for automatic scaling of the website to meet increased user demand. Additionally, creating an AMI from the original EC2 instance allows for easy replication of the instance in case of failure.
Comment: Very good explanations!
Comment: C is the only option via deduction logic based on the assumption the CMS database is Aurora compatible. Other solutions don't promise scaling as much as Aurora solution in option C does.
Comment: Just to clarify, the question is vague as we don't know anything about the DB types on the CMS so making an assumption that Aurora will work with the CMS.
Comment: A and B involve manual steps and do not include scaling (it's just two fixed instances) D scales the application part but leaves the database on a single EC2 instance which would be neither "highly available" nor "scaleable"
Comment: C. Move the database to Amazon Aurora with a read replica in another Availability Zone. Create an Amazon Machine Image (AMI) from the EC2 instance. Configure an Application Load Balancer in two Availability Zones. Attach an Auto Scaling group that uses the AMI across two Availability Zones.
Comment: Move the database to Amazon Aurora with a read replica in another Availability Zone. Create an Amazon Machine Image (AMI) from the EC2 instance. Configure an Application Load Balancer in two Availability Zones. Attach an Auto Scaling group that uses the AMI across two Availability Zones.
Comment: C. Move the database to Amazon Aurora with a read replica in another Availability Zone. Create an Amazon Machine Image (AMI) from the EC2 instance. Configure an Application Load Balancer in two Availability Zones. Attach an Auto Scaling group that uses the AMI across two Availability Zones.
Comment: The question does not say if the current application is using a relational database, so how we can be sure that it can moved to RDS or aurora as answers A, B & C states? In my opinion the right answer is D.
Comment: In D, you "move the database to a separate EC2 instance" BEFORE creating the AMI for the Auto Scaling group. So you'd still have a single EC2 instance running the database, which would meet neither the availability nor the scalability requirement.
Comment: has all options needed for HA
Comment: Option A does not provide a solution for high availability or scalability. Manually launching another EC2 instance in the same AZ may not ensure high availability, as a failure in that AZ would result in downtime. Option B improves database performance and provides a level of fault tolerance, it does not address the scalability aspect of the website platform. Option C provides both high availability and fault tolerance. Creating an AMI allows for easy replication of the EC2 instance across AZs. Configuring an ALB in two AZs and attaching an ASG ensures scalability and load distribution across multiple instances. Option D does not provide the high availability and scalability required by the company. Scheduled backups to S3 address data protection but do not contribute to website availability or scalability.
Comment: Option C meets the requirements.
Comment: Why not D? Are we just assuming that there will be no write to the db?
Comment: Absolutely C.
Comment: C: This will allow the website platform to be highly available by using Aurora, which provides automatic failover and replication. Additionally, by creating an AMI from the original EC2 instance, the Auto Scaling group can automatically launch new instances in multiple availability zones and use the Application Load Balancer to distribute traffic across them. This way, the website will be able to handle the increased traffic, and will be less likely to go down due to a single point of failure.
Comment: D. Reduce the maximum number of EC2 instances in the development environment's Auto Scaling group This option will configure the development environment in the most cost-effective way as it reduces the number of instances running in the development environment and therefore reduces the cost of running the application. The development environment typically requires less resources than the production environment, and it is unlikely that the development environment will have periods of high traffic that would require a large number of instances. By reducing the maximum number of instances in the development environment's Auto Scaling group, the company can save on costs while still maintaining a functional development environment.
Comment: No, it will not reduce the number of instances being used, since a minimum of 2 will be used at all times.
Comment: But it will keep the number of instances at two, while the production environment has "AT LEAST two".
Comment: A modifies only the ALB target group (= directs traffic only to one node), but does not affect the number of nodes (and the cost) B balances load between nodes but does not affect the cost C impacts the prod environment so that would be unable to handle its "periods of high traffic" D makes sure that the dev environment will not scale to more than 2 instances, as does the prod environment
Comment: chatGPT sucks too. it says A, but A abviously just says reduced the number of Target Group, reduce Target Group does not mean the reduce of EC2 instances themself, so there is no cost saved at all. Thus DDDDDDDDDD....
Comment: So, in short, the question asks for a way to reduce cost wasted with the dev env, since it's resources are being underused. (A)Target group vs (B) Auto Scaling Group. Reducing the target group won't affect the number of "nodes" (instances), cost will stay the same. To eliminate the excess of ec2 instances in the dev env, you actually need to reduce the auto scaling group.
Comment: The application uses an Application Load Balancer (ALB) to direct traffic to at least two Amazon EC2 instances in a single target group You are required to keep at least two instances in each target group. A sets it to one, which would be more cost effective, but doesnt meet the requirement.
Comment: In the question it is said minimum it should have 2 instances in Target group. So in development group we can reduce the the target group. In option A. It is said it will have only one instance in development group that doesn't match to our question
Comment: B and C don't actually save any cost without impacting performance during high traffic on production. A and D are basically same thing but A enforces a limit of one EC2 instance which is not acceptable as the question asks: "Application Load Balancer (ALB) to direct traffic to at least two Amazon EC2 instances in a single target group. The instances are in an Auto Scaling group for each environment" Hence D is the only valid answer.
Comment: The most cost-effective solution is to reconfigure the target group in the development environment to have only one EC2 instance as a target. This will ensure that the development environment only uses the resources that it needs, which will save the company money. The other solutions are not as cost-effective. Changing the ALB balancing algorithm to least outstanding requests will not reduce the number of EC2 instances that are used, and it may actually increase the amount of traffic that is directed to each instance. Reducing the size of the EC2 instances will also not reduce the number of instances that are used, and it may actually make the application slower. Reducing the maximum number of EC2 instances in the development environment's Auto Scaling group will only reduce the number of instances that are used when the traffic is high, and it will not reduce the number of instances that are used on average. Therefore, the most cost-effective solution is to reconfigure the target group in the development environment to have only one EC2 instance as a target.
Comment: No, you're confusing "target group" (of the ALB) with "Auto Scaling group". Answer A will direct ALB traffic only to one node, but it does not affect the number of nodes in any way (it will still be "at least two").
Comment: By reconfiguring the target group in the development environment to have only one EC2 instance as a target, it reduces the number of instances handling the development environment's traffic. This ensures the minimum setup required for the development environment's functionality without incurring unnecessary costs associated with multiple instances. This solution optimizes costs by scaling down the infrastructure specifically in the development environment where lower traffic or fewer resources might be acceptable for testing or development purposes, thus reducing unnecessary expenses related to running multiple instances.
Comment: No, you're confusing "target group" (of the ALB) with "Auto Scaling group". Answer A will direct ALB traffic only to one node, but it does not affect the number of nodes in any way (it will still be "at least two").
Comment: the correct answer is D. This is from Amazon Q : The most cost-effective way to configure the development environment would be to reduce the maximum number of EC2 instances in the development environment's Auto Scaling group (Option D). The most cost-effective way to configure the development environment would be to reduce the maximum number of EC2 instances in the development environment's Auto Scaling group (Option D).The most cost-effective way to configure the development environment would be to reduce the maximum number of EC2 instances in the development environment's Auto Scaling group (Option D).
Comment: Option D: Reducing the maximum number of EC2 instances in the development environment's Auto Scaling group could limit scalability but might not directly optimize costs. Min can still be the same number of EC2
Comment: "might not directly optimize." No, it does, you're paying less for fewer machines. This is the most direct cost optimisation practice there could ever be. The correct answer is D
Comment: No, you're confusing "target group" (of the ALB) with "Auto Scaling group". Answer A will direct ALB traffic only to one node, but it does not affect the number of nodes in any way (it will still be "at least two").
Comment: Answear is A but I'am not agree. We use only one instance with A and D. But with D, by default, instance is terminated whereas with A, instance still exist. Answear should be D
Comment: This option is specific to the development environment and focuses on reducing the number of instances that can be spun up during scaling events. This means cost savings because fewer instances will be used even if the scaling policies are triggered. Given the goal to configure the development environment in the most cost-effective way, without compromising the production environment, the best option is D
Comment: Option A
Comment: wont think much about this, option A is the most cost effective
Comment: Wrong, think more. A reduces to one instance whereas: "The application uses an Application Load Balancer (ALB) to direct traffic to at least two Amazon EC2 instances in a single target group" The ALB NEEDS at least 2 instances so where is your second instance?
Comment: Option A because it can't be option D as there should be at least two EC2 instances in Auto scaling group, and can't be reduced to one as said in option D. So, simply reconfigure the target group in the development environment to have only one EC2 instance as a target as said in option A to reduce cost.
Comment: No, you're confusing "target group" (of the ALB) with "Auto Scaling group". Answer A will direct ALB traffic only to one node, but it does not affect the number of nodes in any way (it will still be "at least two").
Comment: Option A because it can't be option D as there should be at least two EC2 instances in Auto scaling group, and can't be reduced to one as said in option D. So, simply reconfigure the target group in the development environment to have only one EC2 instance as a target as said in option A to reduce cost.
Comment: plz remove this comment as i mistakely voted option D here. I have posted another comment above.
Comment: I think either the question or the answers are not formulated correctly because of this document: https://docs.aws.amazon.com/prescriptive-guidance/latest/load-balancer-stickiness/subnets-routing.html A - Might be possible but it's quite impractical B - Not needed as the setup described should work as is provided the SGs of the EC2 instances accept traffic from the ALB C - Update the route tables for the EC2 instances' subnets to send 0.0.0.0/0 traffic through the internet gateway route - not needed as the EC2 instances would receive the traffic from the ALB ENIs. Add a rule to the EC2 instances' security groups to allow outbound traffic to 0.0.0.0/0 - the default behaviour of the SG is to allow outbound traffic only. D - Create public subnets in each Availability Zone. Associate the public subnets with the ALB - if it's a internet facing ALB these should already be in place. Update the route tables for the public subnets with a route to the private subnets - no need as the local prefix entry in the route tables would take care of this point I'm 110% sure the question or answers or both are wrong. Prove me wrong! :)
Comment: Completely agreed, I was looking for an option to allow HTTPS traffic on port 443 from the ALB to the EC2 instance's security group. Either the question or the answers are wrong.
Comment: I change my answer to 'D' because of following link: https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
Comment: Can a EC2 in the private subnet sends traffic to the internet through ELB without using NAT gateway/instance? if it's only about responses to requests coming through the ELB then no, you don't need NAT. If on the other hand you expect that your instances will need to initiate connections as oppose to just sending responses to the requests then yes, you will have to use NAT. The key point is that response to a request is not a new connection and will be sent to where it came from, i.e. to the ELB. https://serverfault.com/questions/986447/can-a-ec2-in-the-private-subnet-sends-traffic-to-the-internet-through-elb-withou
Comment: D looks the best but still it must have a internet gateway and once it has internet gateway we must add the route table for private subnet to talk to the public subnet so by using the it should be able to access. I don't think lb can act like internet gateway
Comment: Considering these statements: -The EC2 instances are in private subnets. - However, the internet traffic is not reaching the EC2 instances. A reliable solution is D according to following link: https://repost.aws/knowledge-center/public-load-balancer-private-ec2 Answer C could not satisfy the requirements because only outbound traffic rules are mentionned
Comment: A - "NAT gateway" is "to allow [outbound] internet traffic", but this is about inbound traffic B - This is about outbound traffic while the problem is inbound C - This is about outbound traffic while the problem is inbound D - Sounds correct, though the "update the route tables" should not be required if both subnets are in same VPC
Comment: D is the "least wrong" answer here. I was also confused by the route table part and thought I was missing something critical in the question.
Comment: this is a bad formulated question with gaps, but my reason tells me that if you want to connect something from a private subnet to internet you need a NAT (instance or gateway, bastion). Creating public subnets in each Availability Zone and associating them with the Application Load Balancer (ALB) won't resolve the problem of allowing internet traffic to reach the private EC2 instances. Public subnets are typically used when you want your EC2 instances to have direct internet access, not when you want to keep them in private subnets with indirect access through a load balancer.
Comment: ption A (replace ALB with Network Load Balancer and add a NAT gateway) is not the most straightforward solution because it changes the load balancer type and introduces a NAT gateway, which might be unnecessary if the goal is to use an ALB for web traffic. ALBs are commonly used for internet-facing web applications. Option B (move EC2 instances to public subnets and modify security group rules) involves placing instances in public subnets, which is generally not recommended for security reasons. Additionally, it suggests modifying security group rules for outbound traffic, which might not be the best practice to resolve the issue. Option C (update route tables and security group rules) addresses the route table update, but it also suggests moving instances to public subnets, which is not ideal from a security perspective.
Comment: Create public subnets in each Availability Zone. Associate the public subnets with the ALB. Update the route tables for the public subnets with a route to the private subnets.
Comment: Option A is incorrect Internet traffic is http and https so it cant be configured to NLB Option B and option C is incorrect because senging 0.0.0.0/0 is not best practices Option D is correct because its the only option left. and updating the route tables for the public subnets with a route to the private subnets ensures internet access to EC2 instances in private subnet.
Comment: D. is the correct solution. By creating public subnets and associating them with the ALB, inbound internet traffic can reach the ALB. The route tables for the public subnets are updated to include a route to the private subnets, allowing traffic to reach the EC2 instances in the private subnets. This setup enables secure access to the application while allowing internet traffic to reach the EC2 instances through the ALB.
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html
Comment: A. suggests using a different type of load balancer and configuring a NAT gateway, but it does not address the issue of internet traffic reaching the EC2 instances. B. suggests exposing the EC2 instances to the public internet, which may pose security risks and does not address the issue of inbound internet traffic reaching the instances. C. suggests configuring the EC2 instances to have outbound internet access, but it does not solve the problem of inbound internet traffic reaching the instances. D. is the correct solution. By creating public subnets and associating them with the ALB, inbound internet traffic can reach the ALB. The route tables for the public subnets are updated to include a route to the private subnets, allowing traffic to reach the EC2 instances in the private subnets. This setup enables secure access to the application while allowing internet traffic to reach the EC2 instances through the ALB.
Comment: Should be C It would normally make sense to segregate your ALBs into public or private zones by security group and target group, but this is configuration rather than architectural placement - there is nothing preventing you from adding a rule to route specific paths or ports to a public subnet from an ALB that has until then been serving private subnets only.
Comment: C allows the EC2 instances to be accessed directly from the Internet, which we don't want. It's the ALB (not the Internet) that can't access them. We must make sure that the ALB can be reached from the Internet and that the EC2 instances can be reached from the ALB.
Comment: To attach Amazon EC2 instances that are located in a private subnet, first create public subnets
Comment: I vote with the option D.
Comment: D is not quite accurate because subnets in a VPC have a local route by default, meaning that all subnets are able to communicate with each other: "Every route table contains a local route for communication within the VPC. This route is added by default to all route tables". This question is poorly formulated.
Comment: Who would know this stuff man...
Comment: exactly
Comment: "Allow long-running transactions to complete on the source DB instance." --. Makes sense / Also a backup before changing anything again made a sense.
Comment: Just take an intelligent guess. Eliminate 2 wrong answers and you will have a 50percent success chance.
Comment: C,E "An active, long-running transaction can slow the process of creating the read replica. We recommend that you wait for long-running transactions to complete before creating a read replica. If you create multiple read replicas in parallel from the same source DB instance, Amazon RDS takes only one snapshot at the start of the first create action. When creating a read replica, there are a few things to consider. First, you must enable automatic backups on the source DB instance by setting the backup retention period to a value other than 0. This requirement also applies to a read replica that is the source DB instance for another read replica" https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
Comment: A isn't correct because binary log is just for external DB instance.
Comment: Answer is C and E https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
Comment: A. Enable binlog replication on the RDS primary node: Direct Impact: Enabling binlog replication is crucial for setting up read replicas, which will directly help in distributing the read load and improving read performance. E. Enable automatic backups on the source instance by setting the backup retention period to a value other than 0: Direct Impact: Automatic backups are necessary to ensure data integrity when creating read replicas. This setup is critical for maintaining consistent and reliable replicas.
Comment: B and D don't have anything to do with the question. E is a must have before doing major architecture changes A is not something you need to do explicitly when creating read replicas as it is managed by RDS C makes sense * I think the options are really badly worded which makes it confusing. I doubt this is a real question.
Comment: Also, to add, binlog replication is needed if you are replicating to a non RDS instance. This is why I think the question is badly phrased as it does not specify the location of read replica. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.External.Repl.html
Comment: An active, long-running transaction can slow the process of creating the read replica. We recommend that you wait for long-running transactions to complete before creating a read replica. If you create multiple read replicas in parallel from the same source DB instance, Amazon RDS takes only one snapshot at the start of the first create action. When creating a read replica, there are a few things to consider. First, you must enable automatic backups on the source DB instance by setting the backup retention period to a value other than 0. This requirement also applies to a read replica that is the source DB instance for another read replica
Comment: To improve the read performance of a database in Amazon RDS for MySQL by adding a read replica, you should take the following actions: Enable binlog replication on the RDS primary node: This allows the primary node to stream its binary logs to the read replica, enabling data replication. A. Enable binlog replication on the RDS primary node. Allow long-running transactions to complete on the source DB instance: Before creating a read replica, it's advisable to let any long-running transactions complete to ensure consistency between the source and the replica. C. Allow long-running transactions to complete on the source DB instance. The other options are not directly related to setting up a read replica:
Comment: B. Choose a failover priority for the source DB instance: Failover priority is more relevant in a Multi-AZ setup where automatic failover might occur. It's not directly related to creating a read replica. D. Create a global table and specify the AWS Regions where the table will be available: Global tables are used for cross-region replication, but they are not directly related to setting up a read replica for improved read performance. E. Enable automatic backups on the source instance by setting the backup retention period to a value other than 0: While it's a good practice to have backups enabled, it is not a prerequisite for creating a read replica. Therefore, the most appropriate actions are A and C.
Comment: A - it's essential for continuous replication E - it's essential for setting up replication, initial data in replica is based on latest backup other options: B - we're not designing for HA, and it's related to mutli-AZ RDS deployments C - is this needed for adding read replica? D - it's not a dynamodb to create global table
Comment: A. Enabling binlog replication is not something you need to do manually before creating a read replica. Amazon RDS for MySQL manages replication internally, and it's not necessary to enable binlog replication explicitly. B. Choosing a failover priority is related to Multi-AZ configurations and automatic failover, but it is not specifically required when adding a read replica. D. Creating a global table and specifying AWS Regions is related to Aurora Global Databases, which is not the same as creating a read replica for a standard RDS instance.
Comment: **C. Long-running transactions can prevent the read replica from catching up with the source DB instance. Allowing these transactions to complete before creating the read replica can help ensure that the replica is able to stay synchronized with the source. **E. Automatic backups must be enabled on the source DB instance for read replicas to be created. This is done by setting the backup retention period to a value other than 0.
Comment: Bin log (binary log) is a specific terminology to MySQL, it is a write-only file that logs all history and used for purposes such as point-in-time recovery and transaction replication. Option A is technically correct but on AWS RDS, this MySQL feature is turned on by setting backup retention period > 0, that is why we must enable backup before replication can work (for MySQL, at least) => Option E is the more general answer for AWS RDS. Option C is just a recommendation from AWS official documentation, it is there to prevent data mismatch on primary and secondaries when the long-running transactions have not been complete yet.
Comment: Before a MySQL DB instance can serve as a replication source, make sure to enable automatic backups on the source DB instance. To do this, set the backup retention period to a value other than 0. This requirement also applies to a read replica that is the source DB instance for another read replica. Automatic backups are supported for read replicas running any version of MySQL. You can configure replication based on binary log coordinates for a MySQL DB instance https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.ReadReplicas.html
Comment: A E. Binlog is needed for on-going replication setup and DB backup is needed for setup the replication DB
Comment: Correction: c and e
Comment: A and e
Comment: A. enables the binary log replication feature on the RDS primary node, which is necessary for setting up a read replica. B. determines the order in which DB instances are promoted to the primary role during a failover scenario. It is not directly related to adding a read replica to address slow reads. C. ensures that any ongoing transactions on the source DB instance are allowed to finish before implementing the change. It helps maintain data integrity and consistency during the transition to the read replica. D. is a feature specific to DynamoDB. It allows for multi-region replication and high availability in DynamoDB, but it is not applicable in this scenario. E. ensures that regular backups are taken for the source DB instance. This is important for data protection and recovery purposes, as it allows for point-in-time restoration in case of any issues during or after the addition of the read replica.
Comment: D. Route incoming requests to Amazon Simple Queue Service (Amazon SQS). Configure an EC2 Auto Scaling group based on queue size. Update the software to read from the queue. By routing incoming requests to Amazon SQS, the company can decouple the job requests from the processing instances. This allows them to scale the number of instances based on the size of the queue, providing more resources when needed. Additionally, using an Auto Scaling group based on the queue size will automatically scale the number of instances up or down depending on the workload. Updating the software to read from the queue will allow it to process the job requests in a more efficient manner, improving the performance of the system.
Comment: D is correct
Comment: The based on the queue size doesn't seem a perfect approach though
Comment: D: Because this whole exam seems to be selling more and more SQS solutions...
Comment: Route incoming requests to Amazon Simple Queue Service (Amazon SQS). Configure an EC2 Auto Scaling group based on queue size. Update the software to read from the queue
Comment: D. Route incoming requests to Amazon Simple Queue Service (Amazon SQS). Configure an EC2 Auto Scaling group based on queue size. Update the software to read from the queue.
Comment: I would vote A if it was ALB targeting an EC2 auto scaling group. I would vote D if the auto scaling group was based on CPU utilization rather than queue size. So I think both answers are wrong but D is okay enough.
Comment: A. Creating a copy of the instance and placing all instances behind an ALB does not address the high CPU utilization issue or provide scalability based on user load. B. Creating an S3 VPC endpoint for S3 and updating the software to reference the endpoint improves network performance but does not address the high CPU utilization or provide scalability based on user load. C. Stopping the EC2 instances and modifying the instance type to one with a more powerful CPU and more memory may improve performance, but it does not address scalability based on user load. D. Routing incoming requests to SQS, configuring an EC2 ASG based on queue size, and updating the software to read from the queue improves system performance and provides scalability based on user load. Therefore, option D is the correct choice as it addresses the high CPU utilization, improves system performance, and enables scalability based on user load.
Comment: Autoscaling Group and SQS solves the problem. SQS - Decouples the process ASG - Autoscales the EC2 instances based on usage
Comment: its definitely A
Comment: You don't "scale the system by load" by choosing A
Comment: D is correct. Decouple the process. autoscale the EC2 based on query size. best choice
Comment: I think it's A " A. Create a copy of the instance. Place all instances behind an Application Load Balancer.
Comment: SMB + fully managed = fsx for windows imo
Comment: Amazon FSx has native support for Windows file system features and for the industry-standard Server Message Block (SMB) protocol to access file storage over a network. https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html
Comment: All the answers are wrong here by people. We don't know whether the user is using Windows based applications. AWS Storage Gateway also supports SMB protocol. This is the answer.
Comment: A: Volume Gateway provides virtual disks iSCSI, not SMB B: Tape Gateway provides virtual tapes via iSCSI, not SMB C: Not "fully managed"
Comment: SMB = Amazon FSx for Windows File Server
Comment: D. Create an Amazon FSx for Windows File Server file system. Attach the file system to the origin server. Connect the application server to the file system
Comment: All who selected D. are correct - see more details from our community
Comment: Fsx is fully managed. Plus it supports SMB protocol
Comment: A. involves using Storage Gateway, but it does not specifically mention support for SMB clients. It may not meet the requirement of using SMB clients to access data. B. involves using Storage Gateway with tape gateway configuration, which is primarily used for archiving data to S3. It does not provide native support for SMB clients to access data. C. involves manually setting up and configuring a Windows file share on an EC2 Windows instance. While it allows SMB clients to access data, it is not a fully managed solution as it requires manual setup and maintenance. D. involves creating an FSx for Windows File Server file system, which is a fully managed Windows file system that supports SMB clients. It provides an easy-to-use shared storage solution with native SMB support. Based on the requirements of using SMB clients and needing a fully managed solution, option D is the most suitable choice.
Comment: Amazon FSx for Windows File Server file system
Comment: amazon fsx for smb connectivity.
Comment: FSX is the ans
Comment: https://www.examtopics.com/discussions/amazon/view/81115-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: D. Create an Amazon FSx for Windows File Server file system. Attach the file system to the origin server. Connect the application server to the file system.
Comment: A. suggests using CloudWatch as the target for VPC Flow Logs. However, it does not provide a mechanism for managing the retention of the logs for 90 days and then accessing them intermittently. B. suggests using Kinesis as the target for VPC Flow Logs. While it can retain the logs for 90 days, it does not address the requirement for intermittent access to the logs. C. suggests using CloudTrail as the target for VPC Flow Logs. However, CloudTrail is designed for auditing and monitoring API activity, not for capturing network traffic logs. It does not meet the requirement of capturing VPC Flow Logs. D. suggests using S3 as the target for VPC Flow Logs and leveraging S3 Lifecycle policies to transition the logs to a cost-effective storage class after 90 days. It meets the requirement of retaining the logs for 90 days and provides the flexibility for intermittent access while optimizing storage costs.
Comment: D is the correct answer.
Comment: D is the correct answer
Comment: A is correct You can change the log data retention setting for CloudWatch logs. By default, logs are kept indefinitely and never expire. You can adjust the retention policy for each log group, keeping the indefinite retention, or choosing a retention period between 10 years and one day. https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html
Comment: Use Amazon S3 as the target. Enable an S3 Lifecycle policy to transition the logs to S3 Standard-Infrequent Access (S3 Standard-IA) after 90 days
Comment: D. Use Amazon S3 as the target. Enable an S3 Lifecycle policy to transition the logs to S3 Standard-Infrequent Access (S3 Standard-IA) after 90 days.
Comment: S3 will store logs. With life cycle, we can move it to different class. With Option A, log groups expiration will simply remove the logs and failing the 2nd request in question
Comment: A doesn't solve "90 days and then accessed intermittently" this statement. It sets expire after 90. Not sure otherwise A seems to be right choice since you can create dashboards etc.
Comment: Option A meets these requirements.
Comment: "Expiration of 90 days", but you need to access the log AFTER 90 days, just "intermittently".
Comment: There's a table here that specifies that VPC Flow logs can go directly to S3. Does not need to go via CloudTrail and then to S3. Nor via CW. https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-S3
Comment: we need to preserve logs hence D https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogsConcepts.html
Comment: D...agree that retention is the key word
Comment: a is not,retantion means delete after 90 days but questions say rarely access.
Comment: D. Use Amazon S3 as the target. Enable an S3 Lifecycle policy to transition the logs to S3 Standard-Infrequent Access (S3 Standard-IA) after 90 days. By using Amazon S3 as the target for the VPC Flow Logs, the logs can be easily stored and accessed by the security team. Enabling an S3 Lifecycle policy to transition the logs to S3 Standard-Infrequent Access (S3 Standard-IA) after 90 days will automatically move the logs to a storage class that is optimized for infrequent access, reducing the storage costs for the company. The security team will still be able to access the logs as needed, even after they have been transitioned to S3 Standard-IA, but the storage cost will be optimized.
Comment: I prefer D "accessed intermittently" need logs after 90 days
Comment: No, D should be is correct. "The logs will be frequently accessed for 90 days and then accessed intermittently." => We still need to store instead of deleting as the answer A.
Comment: D looks correct. This will meet the requirements of frequently accessing the logs for the first 90 days and then intermittently accessing them after that. S3 standard-IA is a storage class that is less expensive than S3 standard for infrequently accessed data, so it would be a more cost-effective option for storing the logs after the first 90 days.
Comment: B. Create a NAT gateway, and place it in a public subnet. Configure the private subnet route table to use the NAT gateway as the default route. This approach will allow the EC2 instance to access the internet and download the monthly security updates while still being located in a private subnet. By creating a NAT gateway and placing it in a public subnet, it will allow the instances in the private subnet to access the internet through the NAT gateway. And then, configure the private subnet route table to use the NAT gateway as the default route. This will ensure that all outbound traffic is directed through the NAT gateway, allowing the EC2 instance to access the internet while still maintaining the security of the private subnet.
Comment: NAT gateway does not allow internet on it's own. It needs internet gateway too. None of the answers make sense
Comment: refer below link https://aws.amazon.com/about-aws/whats-new/2021/06/aws-removes-nat-gateways-dependence-on-internet-gateway-for-private-communications/
Comment: lol, thats for 'private connections'
Comment: B says "place it in a public subnet", a public subnet needs an Internet Gateway so that is included in the answer.
Comment: B. Create a NAT gateway, and place it in a public subnet. Configure the private subnet route table to use the NAT gateway as the default route. Explanation: NAT Gateway: NAT (Network Address Translation) gateway is a managed service provided by AWS that allows EC2 instances in private subnets to access the internet while preventing inbound traffic from directly accessing them. You place the NAT gateway in a public subnet with an associated internet gateway, allowing it to send traffic to the internet. Private Subnet Route Table: Configure the route table of the private subnet to route all outbound traffic (0.0.0.0/0) through the NAT gateway. This allows instances in the private subnet to access the internet through the NAT gateway while maintaining their private IP addresses and security.
Comment: A - if you "configure the private subnet route table to use the internet gateway" then it's no longer a private subnet B - Correct (you place NAT GW in a public subnet and add it to the private subnet's route table) C - NAT instance is deprecated, and it would still in a private subnet where it doesn't have Internet access D - NAT instance is deprecated, and in that answer it is created but not even used
Comment: yes, the nat gateway on its own does not allow connection to the internet. But the question specifies that it has been placed in a public subnet. public subnets are public because they have access to the internet via an internet gateway.
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html Public subnet – The subnet has a direct route to an internet gateway. Resources in a public subnet can access the public internet. Private subnet – The subnet does not have a direct route to an internet gateway. Resources in a private subnet require a NAT device to access the public internet. Both B and C have caveats but are both viable: C - NAT Instance is used as a NAT device instead of NAT gateway, but it's still viable option B - Have 2 redundant components - IGW and public subnet, and NAT gateway still would route traffic to IGW, and if VPC is a custom VPC routing has to be set up
Comment: "NAT instance in the same subnet where the EC2 instance is located", how would you "use the NAT instance as the default route" when it's in the same subnet?
Comment: A NAT Gateway should have one interface in each network it is connected to. I don't understand what it means when they say it is located either in the private or in the public network. It should be in both. Therefore, B and D do not really make sense. I choose D over B because there is a requirement to access the internet and although it is possible for the NAT to exist without an internet gateway, the later is still needed when internet access is required which is the case in this scenario.
Comment: NAT Gateway must be in a public subnet as it needs Internet access. It can be specified in a private subnet's route table as a destination. D doesn't make sense because you created an (outdated) NAT instance but don't use it (you point the route table to the Internet Gateway).
Comment: Internet Gateway is required anyway to access the internet. Option B makes more sense: Create a NAT gateway, and place it in a public subnet. Configure the private subnet route table to use the NAT gateway as the default route.
Comment: B. Create a NAT gateway, and place it in a public subnet. Configure the private subnet route table to use the NAT gateway as the default route.
Comment: A. provides direct internet access to the private subnet, which is not desired in this case as the goal is to restrict outbound internet access. B. allows the EC2 in the private subnet to access the internet through the NAT gateway, which acts as a proxy. It provides controlled outbound internet access while maintaining the security of the private subnet. C. is similar to using a NAT gateway, but it involves using a NAT instance. NAT instances require more manual configuration and management compared to NAT gateways, making them a less preferred option. D. combines the use of an internet gateway and a NAT instance, which is not necessary. It introduces unnecessary complexity and adds a NAT instance that requires additional management. Overall, option B is the most appropriate solution as it utilizes a NAT gateway placed in a public subnet to enable controlled outbound internet access for the EC2 instance in the private subnet. NAT Gateways are preferred over NAT Instances by AWS and in general.
Comment: Option B meets the reqiurements, hence B is right choice.
Comment: D would have been the answer if NAT gateway is installed in public subnet and not where EC2 is located. None of the answers are correct.
Comment: why not C?
Comment: Because NAT Gateways are preferred over NAT Instances by AWS and in general. I have yet to find a situation where a NAT Instance would be more applicable than NAT Gateway which is fully managed and is overall an easier solution to implement - both in AWS questions or the real world.
Comment: Require NAT gateway
Comment: Answer explained here https://medium.com/@tshemku/aws-internet-gateway-vs-nat-gateway-vs-nat-instance-30523096df22
Comment: NAT Gateway is right choice
Comment: https://www.examtopics.com/discussions/amazon/view/59966-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: EFS Amazon Elastic File System (EFS) automatically grows and shrinks as you add and remove files with no need for management or provisioning.
Comment: my choice is A but I think a better alternative would be S3 standard if offered wouldn't it be?
Comment: File system, scalable, multiple access = Amazon Elastic File System (Amazon EFS)
Comment: Amazon Elastic File System (Amazon EFS)
Comment: EFS provides a scalable and fully managed file storage service that can be accessed concurrently from multiple EC2. It offers built-in redundancy by storing data across multiple AZs within a region. With EFS, the client case files can be accessed by multiple application servers simultaneously, ensuring high availability and scalability as the number of files grows over time. Option B, EBS, is a block-level storage service that is typically used for attaching to individual EC2 and does not provide concurrent access to multiple instances, making it unsuitable for this scenario. Option C, S3 Glacier Deep Archive, is a long-term archival storage service and may not be suitable for active file access and simultaneous access from multiple application servers. Option D, AWS Backup, is a centralized backup management service and does not provide the required simultaneous file access and redundancy features. Therefore, the most suitable solution is Amazon EFS (option A).
Comment: Option A meets the requirements, hence A is correct answer.
Comment: What does "The solution must have built-in redundancy" mean
Comment: If the application servers are running on Linux or UNIX operating systems, EFS is a the most suitable solution for the given requirements.
Comment: "accessible from multiple application servers that run on Amazon EC2 instances"
Comment: Correct answer is A
Comment: https://www.examtopics.com/discussions/amazon/view/68833-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: ec2:* Allows full control of EC2 instances, so C is correct The policy only grants get and list permission on IAM users, so not A ds:Delete deny denies delete-directory, so not B, see https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ds/index.html The policy only grants get and describe permission on logs, so not D
Comment: great explanation
Comment: Explicite deny on directories, only available action for deleting is EC2
Comment: This question and answers feel like a fever dream. what the hell is happening.
Comment: Deleting Amazon EC2 instances
Comment: C : Deleting Amazon EC2 instances
Comment: Answer is C
Comment: C : Deleting Amazon EC2 instances
Comment: https://www.examtopics.com/discussions/amazon/view/27873-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: B. Create security group rules using the security group ID as the source or destination. This way, the security team can ensure that the least privileged access is given to the application tiers by allowing only the necessary communication between the security groups. For example, the web tier security group should only allow incoming traffic from the load balancer security group and outgoing traffic to the application tier security group. This approach provides a more granular and secure way to control traffic between the different tiers of the application and also allows for easy modification of access if needed. It's also worth noting that it's good practice to minimize the number of open ports and protocols, and use security groups as a first line of defense, in addition to network access control lists (ACLs) to control traffic between subnets.
Comment: By using security group IDs, the ingress and egress rules can be restricted to only allow traffic from the necessary source or destination, and to deny all other traffic. This ensures that only the minimum required traffic is allowed between the application tiers. Option A is not the best choice because using the instance ID as the source or destination would allow traffic from any instance with that ID, which may not be limited to the specific application tier. Option C is also not the best choice because using VPC CIDR blocks would allow traffic from any IP address within the VPC, which may not be limited to the specific application tier. Option D is not the best choice because using subnet CIDR blocks would allow traffic from any IP address within the subnet, which may not be limited to the specific application tier.
Comment: Create security group rules using the security group ID as the source or destination. This way, the security team can ensure that the least privileged access is given to the application tiers by allowing only the necessary communication between the security groups. For example, the web tier security group should only allow incoming traffic from the load balancer security group and outgoing traffic to the application tier security group. This approach provides a more granular and secure way to control traffic between the different tiers of the application and also allows for easy modification of access if needed. It's also worth noting that it's good practice to minimize the number of open ports and protocols, and use security groups as a first line of defense, in addition to network access control lists (ACLs) to control traffic between subnets.
Comment: A. would limit the traffic based on specific instances, which may not be the most suitable solution for applying the principle of least privilege between application tiers. B. By using security group IDs in the rules, you can precisely control the traffic between application tiers, allowing only the necessary communication and adhering to the principle of least privilege. C. would apply broad rules based on the entire VPC CIDR blocks, which may not provide the necessary level of granularity required for secure communication between specific application tiers. D. would limit the traffic based on subnet CIDR blocks, which may not be sufficient for ensuring proper security between application tiers. In summary, using security group IDs (Option B) is the recommended approach as it allows for precise control of traffic between application tiers, aligning with the principle of least privilege.
Comment: with option A. How would you use instance ID in security group inbound rules ?
Comment: I vote for option B.
Comment: . Create security group rules using the security group ID as the source or destination
Comment: Security Group Rulesapply to instances https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html
Comment: Correct answer is B
Comment: https://www.examtopics.com/discussions/amazon/view/46463-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: B right https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html
Comment: D. Store the order in the database. Send a message that includes the order number to an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Set the payment service to retrieve the message and process the order. Delete the message from the queue. This approach ensures that the order creation and payment processing steps are separate and atomic. By sending the order information to an SQS FIFO queue, the payment service can process the order one at a time and in the order they were received. If the payment service is unable to process an order, it can be retried later, preventing the creation of multiple orders. The deletion of the message from the queue after it is processed will prevent the same message from being processed multiple times. It's worth noting that FIFO queues guarantee that messages are processed in the order they are received, and prevent duplicates.
Comment: A. is not a suitable solution for preventing the creation of multiple orders. This approach does not guarantee the sequential and reliable processing of orders. B. is not an appropriate solution for preventing the creation of multiple orders. CloudTrail is primarily used for logging and auditing API activity, and invoking a Lambda based on the logged request does not ensure the correct order processing. C. is not a suitable solution. SNS is a publish-subscribe messaging service, and polling it may result in delayed processing and potential order duplication. D. is the correct solution. Using an SQS FIFO ensures that the orders are processed in a sequential and reliable manner, preventing the creation of multiple orders for the same transaction.
Comment: if the backend can not keep up, queue the tasks.
Comment: D. Store the order in the database. Send a message that includes the order number to an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Set the payment service to retrieve the message and process the order. Delete the message from the queue.
Comment: The question is related in breaking down the flow. SQS is go-to choice to decouple & DB will be used to store
Comment: Why not A?
Comment: Because Kinesis Data Firehose is for ingestion of streaming data, not queuing items.
Comment: The use of a FIFO queue in Amazon SQS ensures that messages are processed in the order they are received.
Comment: https://www.examtopics.com/discussions/amazon/view/95026-exam-aws-certified-solutions-architect-associate-saa-c03/
Comment: asnwer is d
Comment: No Brainer: B & D
Comment: Prevent accidental deletion of the documents = Enable MFA Delete on the bucket Ensure that all versions of the documents are available = Enable versioning on the bucket
Comment: Options B & D are the correct answers.
Comment: B. allows multiple versions of objects in the S3 bucket to be stored. This ensures that all versions of the documents are available, even if they are accidentally overwritten or deleted. D. adds an extra layer of protection against accidental deletion of objects in the bucket. With MFA Delete enabled, a user would need to provide an additional authentication factor to successfully delete objects from the bucket. This helps prevent accidental or unauthorized deletions and provides an extra level of security for critical documents. A. would restrict users from modifying or uploading documents. It would not meet the requirement of allowing users to download, modify, and upload documents. C. can control access permissions to the bucket, it does not specifically address the requirement of preventing accidental deletion or ensuring availability of all versions of the documents. E. Encryption focuses on data protection rather than versioning and deletion prevention.
Comment: Options B & D are the correct answers.
Comment: no doubts
Comment: 아몰랑 ㅇㅁㄹㅇㅁㄹ
Comment: b and d ofc
Comment: B & D Definitely.
Comment: B & D is correct
Comment: B and D for sure guys
Comment: https://www.examtopics.com/discussions/amazon/view/21969-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: B - EMR cluster is for Big Data, has nothing to do with this C - invokes the function "on a schedule", but you want to capture events D - Could work, but would be overcomplex and would "affect the speed of EC2 instance launches" (which it should not)
Comment: Right.
Comment: This solution meets the requirements because it is serverless and does not affect the speed of EC2 instance launches. Amazon CloudWatch metric streams can continuously stream CloudWatch metrics to destinations such as Amazon S3. Amazon Kinesis Data Firehose can capture, transform, and deliver streaming data into data lakes, data stores, and analytics services. It can directly put the data into Amazon S3, which can then be used for near-real-time updates in a dashboard.
Comment: Answer A: Near real time --> Amazon Kinesis Data Firehose
Comment: You can use metric streams to continually stream CloudWatch metrics to a destination of your choice, with near-real-time delivery and low latency. Supported destinations include AWS destinations such as Amazon Simple Storage Service and several third-party service provider destinations. Main usage scenarios for CloudWatch metric streams: Data lake— Create a metric stream and direct it to an Amazon Kinesis Data Firehose delivery stream that delivers your CloudWatch metrics to a data lake such as Amazon S3. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html#:~:text=CloudWatch%20metric%20streams
Comment: Kinesis is for data streams not events. So, C
Comment: C invokes the Lambda function "on a schedule". It would collect the scaling status during its runs. But you don't want the hourly status, you want to report "scaling events".
Comment: B. introduces unnecessary complexity and overhead for collecting and sending the EC2 Auto Scaling status data to S3. It is not the most efficient serverless solution for this specific requirement. C. would introduce delays in data updates, as it is not triggered in real-time. Additionally, it adds unnecessary overhead and complexity compared to using a direct data stream. D. introduces additional dependencies and management overhead. It may also impact the speed of EC2 instance launches, which is a requirement that needs to be avoided. Overall, option A provides a streamlined and serverless solution by leveraging CloudWatch metric streams and Kinesis Data Firehose to efficiently capture and store the EC2 Auto Scaling status data in S3 without affecting the speed of EC2 instance launches.
Comment: A: I was thinking D is the answer but the solution should not impact ec2 launches will make the difference and i fast read the question. A is a right choice.
Comment: A because of near real time scenario
Comment: Both A and C are applicable - no doubt there. C is more straightforward and to the point of the question imho.
Comment: While EventBridge can capture events, scheduling Lambda functions to poll data is less efficient and may introduce latency, which would not meet the near-real-time requirement.
Comment: Changing my answer to *A* as the dashboard will provide near-real updates. Unless the lambda is configured to run every minute which is not common with schedules - it is not considered near real-time.
Comment: Serverless solution and near real time
Comment: near real time -eliminates c
Comment: Answer is A
Comment: You can use metric streams to continually stream CloudWatch metrics to a destination of your choice, with near-real-time delivery and low latency. One of the use cases is Data Lake: create a metric stream and direct it to an Amazon Kinesis Data Firehose delivery stream that delivers your CloudWatch metrics to a data lake such as Amazon S3. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html
Comment: Option C, using an Amazon EventBridge rule to invoke an AWS Lambda function on a schedule to send the EC2 Auto Scaling status data directly to Amazon S3, may not be the best choice because it may not provide real-time updates to the dashboard. A schedule-based approach with an EventBridge rule and Lambda function may not be able to deliver the data in near real-time, as the EC2 Auto Scaling status data is generated dynamically and may not always align with the schedule set by the EventBridge rule. Additionally, using a schedule-based approach with EventBridge and Lambda also has the potential to create latency, as there may be a delay between the time the data is generated and the time it is sent to S3. In this scenario, using Amazon CloudWatch and Kinesis Data Firehose as described in Option A, provides a more reliable and near real-time solution.
Comment: A seems to be the right answer. Don't think C could be correct as it says "near real-time" and C is on schedule
Comment: C. Create an Amazon EventBridge rule to invoke an AWS Lambda function on a schedule. Configure the Lambda function to send the EC2 Auto Scaling status data directly to Amazon S3.
Comment: "On a schedule" but you want to capture events, not a regular status report.
Comment: A seemsright choice but serverless keyword confuses,and cloud watch metric steam is server less too.
Comment: But A is serverless.
Comment: No, D should be correct. "LEAST operational overhead" => Should you fully manage service like Glue instead of manually like the answer A.
Comment: I also think it's D but remember that D requires writing ETL logic in AWS Glue (nothing in question says how complex it will be). AWS Lambda for CSV could be simple also (imagine NodeJS and millions of libraries support or Python's parsing) so both could be operationally on par to each other. Logically D makes more sense but in practice, AWS Glue rarely works with out of the box ETL and becomes a maintenance overhead in itself.
Comment: Here A is the correct answer. The reason here is the least operational overhead. A ==> S3 - Lambda - S3 D ==> S3 - Lambda - Glue - S3 Also, glue cannot convert on fly automatically, you need to write some code there. If you write the same code in lambda it will convert the same and push the file to S3 Lambda has max memory of 128 MB to 10 GB. So, it can handle it easily. And we need to consider cost also, glue cost is more. Hope many from this forum realize these differences.
Comment: We also need to stay with the question, cost was not a consideration in the question.
Comment: Cost is not a factor. AWS Glue is a fully managed service therefore, it's the least operational overhead
Comment: AWS Glue can run your extract, transform, and load (ETL) jobs as new data arrives. For example, you can configure AWS Glue to initiate your ETL jobs to run as soon as new data becomes available in Amazon Simple Storage Service (S3). Clearly you don't need a lambda function to initiate the ETL job. https://aws.amazon.com/glue/#:~:text=to%20initiate%20your-,ETL,-jobs%20to%20run Option A requires writing code to perform the file conversion. In the exam option D would the best answer.
Comment: This solution meets the requirements with the least operational overhead because AWS Glue is a fully managed ETL service that makes it easy to move data between data stores. AWS Glue can read .csv files from an S3 bucket and write the data into Parquet format in another S3 bucket. The AWS Lambda function can be triggered by an S3 PUT event when a new .csv file is uploaded, and it can start the AWS Glue ETL job to convert the file to Parquet format. This solution does not require managing any servers or clusters, which reduces operational overhead.
Comment: D is correct
Comment: A. introduces significant operational overhead. This approach requires managing the Lambda, handling concurrency, and ensuring proper error handling for large file sizes, which can be challenging. B. adds unnecessary complexity and operational overhead. Managing the Spark job, handling scalability, and coordinating the Lambda invocations for each file upload can be cumbersome. C. introduces additional complexity and may not be the most efficient solution. It involves managing Glue resources, scheduling Lambda, and querying data even when no new files are uploaded. Option D leverages AWS Glue's ETL capabilities, allowing you to define and execute a data transformation job at scale. By invoking the ETL job using an Lambda function for each S3 PUT event, you can ensure that files are efficiently converted to Parquet format without the need for manual intervention. This approach minimizes operational overhead and provides a streamlined and scalable solution.
Comment: Both A and D can works, but A is more simple. It's more close to the "Least Operational effort".
Comment: Creating, maintaining and supporting custom code that does the same as a ready-made serverless service is NEVER "least operational effort".
Comment: Oh, and A can't handle 1 GB files.
Comment: Now Lambda support 1 GB to 10 GB.
Comment: The maximum size for a Lambda event payload is 256 KB - so (A) didn't work with 1GB Files. Glue is recommended for the Parquet Transformation of AWS.
Comment: ANS - d https://aws.amazon.com/blogs/database/how-to-extract-transform-and-load-data-for-analytic-processing-using-aws-glue-part-2/ - READ ARTICLE -
Comment: A is unlikely to work as Lambda may struggle with 1GB size: "< 64 MB, beyond which lambda is likely to hit memory caps", see https://stackoverflow.com/questions/41504095/creating-a-parquet-file-on-aws-lambda-function
Comment: Should be D as Glue is self managed service and provides tel job for converting cab files to parquet off the shelf.
Comment: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/three-aws-glue-etl-job-types-for-converting-data-to-apache-parquet.html
Comment: AWS Glue is right solution here.
Comment: I am thinking D. A says lambda will download the .csv...but to where? that seem manual based on that
Comment: I think A
Comment: https://www.examtopics.com/discussions/amazon/view/83201-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A. suggests using AWS Backup, a centralized backup management service, to retain RDS backups. A backup vault is created, and a backup plan is defined with a daily schedule and a 2-year retention period for backups. RDS DB instances are assigned to this backup plan. B. it does not address the requirement for consistent and restorable backups. Snapshots are point-in-time backups and may not provide the desired level of consistency. C. it is not designed to provide the backup and restore functionality required for databases. It does not ensure the backups are consistent or provide an easy restore mechanism. D. it does not address the requirement for daily backups and retention of consistent backups. It focuses more on replication and change data capture rather than backup and restore.
Comment: The solution architect should recommend option B - Configure a backup window for the RDS DB instances for daily snapshots. Assign a snapshot retention policy of 2 years to each RDS DB instance. Use Amazon Data Lifecycle Manager (Amazon DLM) to schedule snapshot deletions. This meets the requirements of: Retaining daily backups for a minimum of 2 years. The daily snapshots captured within the backup window provide consistent, restorable backups on a daily basis. Assigning a snapshot retention policy of 2 years ensures the snapshots are retained for the required period. Using Amazon DLM allows automatically deleting snapshots older than 2 years to comply with the retention period in a cost-effective manner without manual administration. The other option of using AWS Backup vault is not as suitable since it has limitations such as 35 day maximum retention for automated backups. Option B provides a native RDS solution capable of meeting the long term 2 year retention requirements.
Comment: If not specified, AWS Backup Vault Lock will not enforce a maximum retention period. If specified, backup and copy jobs to this vault with lifecycle retention periods longer than the maximum retention period will fail. Recovery points already saved in the vault prior to the vault lock's creation are not affected. The longest maximum retention period you can specify is 36500 days (approximately 100 years).
Comment: Here's why Option B is the best choice: Backup Window: Configuring a backup window for daily snapshots ensures that consistent backups are taken at the specified time each day. This helps maintain data integrity and consistency. Snapshot Retention Policy: Assigning a snapshot retention policy of 2 years to each RDS DB instance ensures that the backups are retained for the required duration. Amazon Data Lifecycle Manager (Amazon DLM): Amazon DLM can be used to automate the management of EBS snapshots, including RDS snapshots. You can configure Amazon DLM to schedule snapshot deletions, making it easier to manage the retention policy without manual intervention. Option A (AWS Backup) is primarily used for managing backups of resources that may not have built-in backup capabilities, but for Amazon RDS, it's better to use the built-in snapshot capabilities and Amazon DLM for snapshot retention.
Comment: "AWS Backup is primarily used for managing backups of resources that may not have built-in backup capabilities" says who?
Comment: Create a backup vault in AWS Backup to retain RDS backups. Create a new backup plan with a daily schedule and an expiration period of 2 years after creation. Assign the RDS DB instances to the backup plan.
Comment: A. Create a backup vault in AWS Backup to retain RDS backups. Create a new backup plan with a daily schedule and an expiration period of 2 years after creation. Assign the RDS DB instances to the backup plan
Comment: Backups work with EBS, FSX, RDS. Its managed & can has vault option for more better control over backup retention
Comment: Why not B?
Comment: A is correct
Comment: Why not D? Creating tasks for ongoing replication using AWS DMS: You can create an AWS DMS task that captures ongoing changes from the source data store. You can do this capture while you are migrating your data. You can also create a task that captures ongoing changes after you complete your initial (full-load) migration to a supported target data store. This process is called ongoing replication or change data capture (CDC). AWS DMS uses this process when replicating ongoing changes from a source data store.
Comment: Requirement is backup, not migration.
Comment: A. Create a backup vault in AWS Backup to retain RDS backups. Create a new backup plan with a daily schedule and an expiration period of 2 years after creation. Assign the RDS DB instances to the backup plan.
Comment: A is right choice
Comment: A A A A A A
Comment: Correct answer is A
Comment: Create a backup vault in AWS Backup to retain RDS backups. Create a new backup plan with a daily schedule and an expiration period of 2 years after creation. Assign the RDS DB instances to the backup plan.
Comment: D. Join the file system to the Active Directory to restrict access. Joining the FSx for Windows File Server file system to the on-premises Active Directory will allow the company to use the existing Active Directory groups to restrict access to the file shares, folders, and files after the move to AWS. This option allows the company to continue using their existing access controls and management structure, making the transition to AWS more seamless.
Comment: D. allows the file system to leverage the existing AD infrastructure for authentication and access control. Option A is incorrect because mapping the AD groups to IAM groups is not applicable in this scenario. IAM is primarily used for managing access to AWS resources, while the requirement is to integrate with the on-premises AD for access control. Option B is incorrect because assigning a tag with a Restrict tag key and a Compliance tag value does not provide the necessary integration with the on-premises AD for access control. Tags are used for organizing and categorizing resources and do not provide authentication or access control mechanisms. Option C is incorrect because creating an IAM service-linked role linked directly to FSx for Windows File Server does not integrate with the on-premises AD. IAM roles are used within AWS for managing permissions and do not provide the necessary integration with external AD systems.
Comment: When you create a file system with Amazon FSx, you join it to your Active Directory domain to provide user authentication and file- and folder-level access control.
Comment: D is relevent and accurate answer when we consider this: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/creating-joined-ad-file-systems.html "When you create a new FSx for Windows File Server file system, you can configure Microsoft Active Directory integration so that it joins to your self-managed Microsoft Active Directory domain. To do this, provide the following information for your Microsoft Active Directory"
Comment: The on-premise AD already has restrictions via group in place so D makes no sense as the groups are already linked to file system. "The company must ensure that the on-premises Active Directory groups restrict access to the FSx for Windows File Server SMB compliance shares, folders, and files after the move to AWS." The question is about linking the on-prem permissions to the new FSx server on AWS and this can only be done by A
Comment: Actually neither A nor D make sense. "A self-managed on-premises Active Directory controls access to the files and folders." This makes D sound useless and at the same time does not allow the on-prem AD to control file access on FSx. A uses IAM roles which is irrelevant to this setup. BC are totally wrong
Comment: Option A: Creating an Active Directory Connector and mapping groups to IAM groups is more relevant for AWS Directory Service, such as AWS Managed Microsoft AD, and not for integrating with existing on-premises Active Directory. Option B: Using tags is typically not used for access control purposes. Tags are metadata and are not directly involved in user authentication and authorization. Option C: Creating an IAM service-linked role directly linked to FSx for Windows File Server is not the standard approach for integrating with existing on-premises Active Directory.
Comment: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/self-managed-AD.html
Comment: This allows the on-premises Active Directory to manage permissions to the FSx file shares, meeting the key requirement to use existing AD groups to control access after migrating to AWS. Joining FSx to the AD domain allows the native file system permissions, users, and groups to be applied from Active Directory. Access is handled seamlessly via the trust relationship between FSx and AD. The other options would not leverage the existing AD identities and groups
Comment: The other options would not leverage the existing AD identities and groups: A) AD Connector and IAM groups would require re-mapping AD groups to IAM, adding complexity. Native AD integration is simpler. B) Tags and IAM groups also don't use native AD semantics. C) Service-linked roles are not applicable for managing end user access. So D is the correct option to meet the requirements using the native Active Directory integration built into FSx for Windows.
Comment: The AD is on-premisses... Your need the connector.
Comment: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/aws-ad-integration-fsxW.html
Comment: Other options are referring to IAM based control which is not possible. Existing AD should be used without IAM.
Comment: https://aws.amazon.com/blogs/storage/using-amazon-fsx-for-windows-file-server-with-an-on-premises-active-directory/
Comment: Answer D. Amazon FSx does not support Active Directory Connector .
Comment: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/self-managed-AD.html
Comment: Note: Amazon FSx does not support Active Directory Connector and Simple Active Directory. https://docs.aws.amazon.com/fsx/latest/WindowsGuide/aws-ad-integration-fsxW.html
Comment: The answer will be AD connector so : A, it will create a proxy between your onpremises AD which you can use to restrict access
Comment: Option D: Join the file system to the Active Directory to restrict access. Joining the FSx for Windows File Server file system to the on-premises Active Directory allows the company to use the existing Active Directory groups to restrict access to the file shares, folders, and files after the move to AWS. By joining the file system to the Active Directory, the company can maintain the same access control as before the move, ensuring that the compliance team can maintain compliance with the relevant regulations and standards. Options A and B involve creating an Active Directory Connector or assigning a tag to map the Active Directory groups to IAM groups, but these options do not allow for the use of the existing Active Directory groups to restrict access to the file shares in AWS. Option C involves creating an IAM service-linked role linked directly to FSx for Windows File Server to restrict access, but this option does not take advantage of the existing on-premises Active Directory and its access control.
Comment: A, C is correct. NLB lister rule only supports Protocol & Port (Not host/based routing like ALB) => D, E is incorrect. NLB just works layer 4 (TCP/UDP) instead of Layer 7 (HTTP) => B is incorrect. After eliminating, AC should be the answer.
Comment: A. allows customers to receive the appropriate version of the content based on their location and device type. C. By creating a Lambda@Edge, you can inspect the User-Agent header of incoming requests and determine the type of device being used. Based on this information, you can customize the response and send the appropriate version of the content to the user.
Comment: A C Configure Amazon CloudFront to cache multiple versions of the content. Configure a [email protected] function to send specific objects to users based on the User-Agent header.
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html
Comment: https://medium.com/swlh/serve-different-content-based-on-user-agent-in-aws-cloudfront-using-lambda-edge-28877294340b
Comment: A. allows customers to receive the appropriate version of the content based on their location and device type. C. By creating a Lambda@Edge, you can inspect the User-Agent header of incoming requests and determine the type of device being used. Based on this information, you can customize the response and send the appropriate version of the content to the user. B. does not address the requirement of serving different content versions based on device types. D. & E. do not address the device-specific content requirement. Therefore, options A and C are the correct combination of actions to meet the requirement of providing different versions of content based on the devices that customers use to access the website.
Comment: NLB does not supports routing
Comment: A C Configure Amazon CloudFront to cache multiple versions of the content. Configure a [email protected] function to send specific objects to users based on the User-Agent header.
Comment: C Configure a [email protected] function to send specific objects to users based on the User-Agent header.
Comment: Using a Directory Connector to connect the on-premises Active Directory to AWS is one way to enable access to AWS resources, including Amazon FSx for Windows File Server. However, joining the Amazon FSx for Windows File Server file system to the on-premises Active Directory is a separate step that allows you to control access to the file shares using the same Active Directory groups that are used on-premises.
Comment: I guess this belongs to the question before #260
Comment: So will this mean the entire architecture needs to move to lambda in order to leverage off lambda edge? This doesn't make sense as the question outlines the architecture already in ec2, asg and elb? Just looking for clarification if I am missing something
Comment: No, Lamba function will just do something like "if user-agent is 'iOS' then send content from elb-01 otherwise send content from elb-02".
Comment: AC are the correct answers. For C: IMPROVED USER EXPERIENCE Lambda@Edge can help improve your users' experience with your websites and web applications across the world, by letting you personalize content for them without sacrificing performance. Real-time Image Transformation You can customize your users' experience by transforming images on the fly based on the user characteristics. For example, you can resize images based on the viewer's device type—mobile, desktop, or tablet. You can also cache the transformed images at CloudFront Edge locations to further improve performance when delivering images. https://aws.amazon.com/lambda/edge/
Comment: Correct answer is A,C
Comment: C. Configure a Lambda@Edge function to send specific objects to users based on the User-Agent header. Lambda@Edge allows you to run a Lambda function in response to specific CloudFront events, such as a viewer request, an origin request, a response, or a viewer response.
Comment: https://www.examtopics.com/discussions/amazon/view/67881-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A. Create a peering connection between the VPCs. Add a route table entry for the peering connection in both VPCs. Configure an inbound rule for the ElastiCache cluster's security group to allow inbound connection from the application's security group. Creating a peering connection between the VPCs allows the application's EC2 instances to communicate with the ElastiCache cluster directly and efficiently. This is the most cost-effective solution as it does not involve creating additional resources such as a Transit VPC, and it does not incur additional costs for traffic passing through the Transit VPC. Additionally, it is also more secure as it allows you to configure a more restrictive security group rule to allow inbound connection from only the application's security group.
Comment: A. Create a peering connection between the VPCs. Add a route table entry for the peering connection in both VPCs. Configure an inbound rule for the ElastiCache cluster's security group to allow inbound connection from the application's security group. Creating a peering connection between the VPCs allows the application's EC2 instances to communicate with the ElastiCache cluster directly and efficiently. This is the most cost-effective solution as it does not involve creating additional resources such as a Transit VPC, and it does not incur additional costs for traffic passing through the Transit VPC. Additionally, it is also more secure as it allows you to configure a more restrictive security group rule to allow inbound connection from only the application's security group.
Comment: Create a peering connection between the VPCs. Add a route table entry for the peering connection in both VPCs. Configure an inbound rule for the ElastiCache cluster's security group to allow inbound connection from the application's security group.
Comment: Create a VPC peering connection between the Cache VPC and App VPC. This allows private IP connectivity between the VPCs. Add route table entries in each VPC to route traffic destined to the other VPC via the peering connection. This enables network routing. Configure security groups to allow inbound connections from the application instances to the ElastiCache cluster.
Comment: Creating a peering connection between the VPCs is a cost-effective way to establish connectivity. By adding a route table entry for the peering connection in both VPCs, traffic can flow between them. Configuring an inbound rule in the ElastiCache cluster's security group allows inbound connections from the application's security group, enabling access to the ElastiCache cluster from the EC2 instances in the App VPC. Option B suggests creating a Transit VPC, which adds unnecessary complexity and cost for this scenario. Option C suggests configuring an inbound rule for the peering connection's security group, which is not necessary as the security group for the ElastiCache cluster should be used to control inbound connections. Option D suggests configuring an inbound rule for the Transit VPC's security group, which is not needed in this case and adds unnecessary complexity. Therefore, option A is the most cost-effective solution to provide the application's EC2 instances with access to the ElastiCache cluster.
Comment: A is correct, 1. VPC transit is used for more complex architecture and can do VPCs to VPCs connectivity. But for simple VPC 2 VPC can use peer connection. 2.To enable private IPv4 traffic between instances in peered VPCs, you must add a route to the route tables associated with the subnets for both instances. So base on 1, B and D are out, base on 2 C is out
Comment: Why not C ? any explanation?
Comment: To enable private IPv4 traffic between instances in peered VPCs, you must add a route to the route tables associated with the subnets for both instances. https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html
Comment: Application read from ElasticCache, not viseversa, so inbound rule should be ElasticCach
Comment: Thank you Sir!
Comment: Cost Effectively!
Comment: Options B and E suggest deploying the Kubernetes control plane and worker nodes on EC2 instances, which would require managing the infrastructure and add ongoing maintenance overhead, contrary to the requirement of minimizing effort. Option C suggests using the Amazon EC2 launch type for ECS, which still requires managing EC2 instances and is not as cost-effective and scalable as using Fargate. Therefore, the combination of deploying an Amazon ECS cluster and an ECS service with a Fargate launch type (options A and D) is the most suitable for minimizing maintenance and scaling effort without managing additional infrastructure.
Comment: Company needs a solution that minimizes the amount of ongoing effort for maintenance and scaling = Serverless = ECS with Fargate.
Comment: ECS allows deploying and managing containers without having to provision the underlying infrastructure. This minimizes maintenance effort. Using Fargate launch type means ECS will handle provisioning and scaling the infrastructure automatically. This removes the management overhead for the company. Running multiple tasks and specifying desired count ≥ 2 will provide high availability across Availability Zones. Together, ECS plus Fargate provide a fully managed container platform. The company doesn't need to provision or manage servers.
Comment: AWS Farget is server less solution to use on ECS: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
Comment: why is c is incorrect ?
Comment: Because in the question says, "minimizes the amount of ongoing effort for maintenance and scaling", and EC2 instances you need effort to maintain the infrastructure unlike fargate that is serverless.
Comment: Amazon Fargate is a service that is fully manageable by Amazon; it offers provisioning, configuration and scaling feature. It is "serverless"..
Comment: ECS has 2 launch type, EC2 (you maintain the infra) and Fargate (serverless). Since the question ask for no additional infra to manage it should be Fargate.
Comment: AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html
Comment: A D is the correct answer
Comment: A,D is correct answer
Comment: AD: https://www.examtopics.com/discussions/amazon/view/60032-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: AD - EC2 out for this, cluster + fargate is the right answer
Comment: ALB performs health checks on the EC2 instances, so it will only route traffic to healthy instances. This avoids the timeout errors. ALB provides load balancing across the instances, improving performance and availability. Route 53 routes to the ALB DNS name, so you don't have to manage records for each EC2 instance. This is a standard and robust architecture for public-facing web applications. The ALB acts as the entry point and handles health checks and scaling.
Comment: It is not clear from the question whether the 10 EC2s are running within the same region. ALB can only direct traffic within region, while route 53 can route traffic to multiple locations, hence C and D are wrong.
Comment: But B has one primary record and 9 failover records. A is correct, simple policy with health checks, that makes sure that only IPs of healthy instances are returned.
Comment: D for sure
Comment: Those who are confused between A and D, A is wrong as you can't associate a health check with Simple routing policy record.
Comment: D is the best answer
Comment: If you focus on the question, both A and D seems to be correct. A is correct because simple routing policy for health check is doable BUT it is also wrong because we don't know how to determine the health of instance. D is correct because " The company occasionally experiences a timeout error when attempting to browse the application" which suggest aplication is being acccessed by a browser with means it's HTTP based and ALB is better for HTTP based healthchecks. A web application timing out is not necessarily unhealthy instance, strictly speaking. It's just bad web application running on a healthy instance! So A may not be correct also.
Comment: Although B can work as well, but it's nor a professional choice to associate the healthcheck with 10 EC2 instances, ALB is better option here. A is incorect: Simple Routing Policies Can't be associated with Health Checks C is incorrect: Cloudfront is for caching content which is irrelevant.
Comment: Simple routing policies can be associated with Health Checks https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-simple-configs.html
Comment: A meets the requirement ("overcome these timeout errors") without any other changes. "If you configure health checking for all the records in a group of records that have the same name, the same type (such as A or AAAA), and the same routing policy (such as weighted or failover), Route 53 responds to DNS queries by choosing a healthy record and returning the applicable value from that record. (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-how-route-53-chooses-records.html)
Comment: "You can use Route 53 health checking to configure active-active and active-passive failover configurations. You configure active-active failover using any routing policy (or combination of routing policies) other than failover. ... Use this failover configuration when you want all of your resources to be available the majority of the time. When a resource becomes unavailable, Route 53 can detect that it's unhealthy and stop including it when responding to queries.
Comment: In active-active failover, all the records that have the same name, the same type (such as A or AAAA), and the same routing policy (such as weighted or latency) are active unless Route 53 considers them unhealthy. Route 53 can respond to a DNS query using any healthy record." (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-types.html#dns-failover-types-active-passive)
Comment: B - No, "you configure active-active failover using any routing policy (or combination of routing policies) OTHER THAN FAILOVER". With B, all traffic would go one primary instance unless it is unhealthy. C - Not sure how to configure multiple EC2 instances as the origin without an LB. Even if that would be possible it would introduce more changes and complexity, which is not asked for. D - Would work if all EC2 instances are in the same region, which we don't know. But it would also incur additional cost and potentially have other effects.
Comment: B is wrong. The DNS cache in clients could drive to timeouts. With ALB this issue won't happen since the DNS register will be the same and ALB will take care of unhealty nodes.
Comment: B is wrong. The DNS cache in clients could drive to timeouts. With ALB this issue won't happen since the DNS register will be the same and ALB will take care of unhealty nodes.
Comment: D. **Application Load Balancer (ALB) with Health Checks, Routed via Route 53**: - Creating an ALB in front of the EC2 instances and configuring health checks on the ALB will ensure that only healthy instances receive traffic. Route 53 can then direct traffic to the ALB, which in turn, routes traffic to healthy instances based on the health check results. Among the provided options, the one that directly addresses the issue of routing traffic only to healthy instances is: **D. Create an Application Load Balancer (ALB) with a health check in front of the EC2 instances. Route to the ALB from Route 53.**
Comment: Clearly the question is all about Amazon Route 53 that has Failover routing policy that is used when you want to configure active-passive failover.
Comment: i was looking at A, but indeed D is the best option, because the usually the TTL of the records is at least 60 seconds (nobody sets lower unless testing something ,because there is a charge per number of unique requests. ALB health check can be set as low as desired, which helps exclude the problematic ec2 faster than the DNS TTL expires
Comment: By creating an ALB and configuring health checks, the architect ensures that only healthy instances receive traffic. The ALB periodically checks the health of the EC2 instances based on the configured health check settings. Routing traffic to the ALB from Route 53 ensures that DNS queries return the IP address of the ALB instead of individual instances. This allows the ALB to distribute traffic only to healthy instances, avoiding timeouts caused by unhealthy instances. A & B: While associating health checks with each record can help identify unhealthy instances, it does not provide automatic load balancing and distribution of traffic to healthy instances. C: While CloudFront can improve performance and availability, it is primarily a CDN and may not directly address the issue of load balancing and distributing traffic to healthy instances. Therefore, option D is the most appropriate solution to overcome the timeout errors by implementing an ALB with health checks and routing traffic through Route 53.
Comment: I believe both C and D will work, but C seems less complex. hopefully somebody here is more advanced(not an old student learning AWS like me) to explain why not C.
Comment: Option D allows for the creation of an Application Load Balancer which can detect unhealthy instances and redirect traffic away from them.
Comment: I vote d
Comment: C. Configure a public Application Load Balancer (ALB) with multiple redundant Amazon EC2 instances in private subnets. Configure Amazon CloudFront to deliver HTTPS content using the public ALB as the origin. This solution meets the requirements for a highly available application with web, application, and database tiers, as well as providing edge-based content delivery. Additionally, it maximizes security by having the ALB in a private subnet, which limits direct access to the web servers, while still being able to serve traffic over the Internet via the public ALB. This will ensure that the web servers are not exposed to the public Internet, which reduces the attack surface and provides a secure way to access the application.
Comment: A. exposes the EC2 instances directly to the public internet, which may compromise security. B. lacks a load balancer in the public subnet, which is required for efficient load distribution and high availability. D. provides load balancing and HTTPS content delivery, it exposes the EC2 instances directly to the public internet, which may pose security risks. C. provides high availability, secure access through private subnets, and optimized HTTPS content delivery using CloudFront with a public ALB as the origin.
Comment: C. Configure a public Application Load Balancer (ALB) with multiple redundant Amazon EC2 instances in private subnets. Configure Amazon CloudFront to deliver HTTPS content using the public ALB as the origin. Here's the reasoning: Public ALB in Private Subnets: Placing the ALB in private subnets enhances security by preventing direct access from the internet. The ALB in private subnets can communicate with the application instances in the same private subnets. CloudFront with ALB as Origin: Configuring CloudFront to deliver HTTPS content using the public ALB as the origin allows for content to be cached and distributed globally, reducing latency for end users.
Comment: C. Configure a public Application Load Balancer (ALB) with multiple redundant Amazon EC2 instances in private subnets. Configure Amazon CloudFront to deliver HTTPS content using the public ALB as the origin. This solution meets the requirements for a highly available application with web, application, and database tiers, as well as providing edge-based content delivery. Additionally, it maximizes security by having the ALB in a private subnet, which limits direct access to the web servers, while still being able to serve traffic over the Internet via the public ALB. This will ensure that the web servers are not exposed to the public Internet, which reduces the attack surface and provides a secure way to access the application.
Comment: Keyword: Instances in private, ALB in public, point cloudfront to the public ALB
Comment: Answer is C
Comment: ans: C https://www.examtopics.com/discussions/amazon/view/46401-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Instances in private, ALB in public, point cloudfront to the public ALB
Comment: A. Configure an accelerator in AWS Global Accelerator. Add a listener for the port that the application listens on, and attach it to a Regional endpoint in each Region. Add the ALB as the endpoint. AWS Global Accelerator directs traffic to the optimal healthy endpoint based on health checks, it can also route traffic to the closest healthy endpoint based on geographic location of the client. By configuring an accelerator and attaching it to a Regional endpoint in each Region, and adding the ALB as the endpoint, the solution will redirect traffic to healthy endpoints, improving the user experience by reducing latency and ensuring that the application is running optimally. This solution will ensure that traffic is directed to the closest healthy endpoint and will help to improve the overall user experience.
Comment: Delivery gaming content --> AWS GLOBAL ACCELERATOR
Comment: Would have selected A just because B, C and D don't make any sense or have nothing to do with the requirements. But now learned that Global Accelerator checks health of resources BEHIND ALB/NLB, so it meets the requirements.
Comment: gaming platform -> Can't be CloudFront. Probably go for global accelerator
Comment: A. Configure an accelerator in AWS Global Accelerator. Add a listener for the port that the application listens on, and attach it to a Regional endpoint in each Region. Add the ALB as the endpoint. AWS Global Accelerator directs traffic to the optimal healthy endpoint based on health checks, it can also route traffic to the closest healthy endpoint based on geographic location of the client. By configuring an accelerator and attaching it to a Regional endpoint in each Region, and adding the ALB as the endpoint, the solution will redirect traffic to healthy endpoints, improving the user experience by reducing latency and ensuring that the application is running optimally. This solution will ensure that traffic is directed to the closest healthy endpoint and will help to improve the overall user experience.
Comment: A. Configure an accelerator in AWS Global Accelerator. Add a listener for the port that the application listens on, and attach it to a Regional endpoint in each Region. Add the ALB as the endpoint
Comment: Is any answer relevant to the question?
Comment: B. While CloudFront can help with caching and content delivery, it does not provide the mechanism to monitor the health of the application or perform traffic redirection based on health checks. C. This configuration is suitable for static content delivery but does not address the health monitoring and traffic redirection requirements of the application. D. While this can enhance performance, it does not monitor the health of the application or redirect traffic based on health checks. Therefore, option A is the most suitable solution as it leverages AWS Global Accelerator to monitor application health, route traffic to healthy endpoints, and optimize the user experience while addressing latency concerns.
Comment: Agree with A
Comment: Global accelerators can be used for non http cases such as UDP, tcp , gaming , or voip
Comment: Though we seem to have http/https here, otherwise they could not use ALBs
Comment: Correct answer is A
Comment: A: https://www.examtopics.com/discussions/amazon/view/46403-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A. When you have an Application Load Balancer or Network Load Balancer that includes multiple target groups, Global Accelerator considers the load balancer endpoint to be healthy only if each target group behind the load balancer has at least one healthy target. If any single target group for the load balancer has only unhealthy targets, Global Accelerator considers the endpoint to be unhealthy. https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups-health-check-options.html
Comment: https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups-health-check-options.html
Comment: D. Create an Amazon Kinesis Data Firehose delivery stream to store the data in Amazon S3. Create an Amazon Kinesis Data Analytics application to analyze the data. This solution will meet the requirements with the least operational overhead as it uses Amazon Kinesis Data Firehose, which is a fully managed service that can automatically handle the data collection, data transformation, encryption, and data storage in near-real time. Kinesis Data Firehose can automatically store the data in Amazon S3 in Apache Parquet format for further processing. Additionally, it allows you to create an Amazon Kinesis Data Analytics application to analyze the data in near real-time, with no need to manage any infrastructure or invoke any Lambda function. This way you can process a large amount of data with the least operational overhead.
Comment: Nicely explained. Thanks.
Comment: Apache Parquet format processing was not mentioned in the answer options. Strange.
Comment: Thanks for the explanation!
Comment: https://aws.amazon.com/blogs/big-data/analyzing-apache-parquet-optimized-data-using-amazon-kinesis-data-firehose-amazon-athena-and-amazon-redshift/
Comment: A. requires invoking an Lambda to send the data to the analytics application. This introduces additional operational overhead and complexity. B. While EMR is a powerful tool for big data processing, it requires more operational management and configuration compared to Kinesis Data Analytics. C. introduces unnecessary complexity by involving EMR for data analysis when Kinesis Data Analytics can perform the analysis in a more streamlined and automated manner. Therefore, option D is the most suitable solution as it leverages Kinesis Data Firehose for data ingestion, stores the data in S3, and utilizes Kinesis Data Analytics for near-real-time analysis, providing a low operational overhead solution for data usage analysis and encryption.
Comment: A and B are out. Kinesis Data Streams cannot directly send data to S3 by itself
Comment: D. Create an Amazon Kinesis Data Firehose delivery stream to store the data in Amazon S3. Create an Amazon Kinesis Data Analytics application to analyze the data. This solution will meet the requirements with the least operational overhead as it uses Amazon Kinesis Data Firehose, which is a fully managed service that can automatically handle the data collection, data transformation, encryption, and data storage in near-real time. Kinesis Data Firehose can automatically store the data in Amazon S3 in Apache Parquet format for further processing. Additionally, it allows you to create an Amazon Kinesis Data Analytics application to analyze the data in near real-time, with no need to manage any infrastructure or invoke any Lambda function. This way you can process a large amount of data with the least operational overhead.
Comment: Create an Amazon Kinesis Data Firehose delivery stream to store the data in Amazon S3. Create an Amazon Kinesis Data Analytics application to analyze the data
Comment: D. Create an Amazon Kinesis Data Firehose delivery stream to store the data in Amazon S3. Create an Amazon Kinesis Data Analytics application to analyze the data
Comment: D: https://www.examtopics.com/discussions/amazon/view/82022-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: D. Create an Amazon Kinesis Data Firehose delivery stream to store the data in Amazon S3. Create an Amazon Kinesis Data Analytics application to analyze the data. Amazon Kinesis Data Firehose can automatically encrypt and store the data in Amazon S3 in Apache Parquet format for further processing, which reduces the operational overhead. It also allows for near-real-time data analysis using Kinesis Data Analytics, which is a fully managed service that makes it easy to analyze streaming data using SQL. This solution eliminates the need for setting up and maintaining an EMR cluster, which would require more operational overhead.
Comment: Rds proxy is for too many connections, not for performance
Comment: RDS Proxy: It helps applications improve scalability and performance by managing database connections and pooling, which can significantly reduce the load on the database
Comment: ElastiCache stores data in memory, which means it may not always have the most up-to-date information. This might be acceptable for certain use cases where slightly stale data is acceptable, but for applications like gaming scores, real-time accuracy is often crucial.
Comment: “Data in the cache is never stale. Because the data in the cache is updated every time it's written to the database, the data in the cache is always current and updated whenever data is written to the database.” https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html#Strategies.WriteThrough
Comment: Can't use cache as score gates updated. If data would have been static then definitely can go with A. But here score is dynamic...
Comment: Users are starting to experience long delays and interruptions caused by the "read performance" of the database... While the score is dynamic, there is also read activity in the DB that is causing the delays and outages and this can be improved with Elastic Cache.
Comment: to use elasticache , you need to perform heavy code change ,aand also elasticache do chaching that can improve read perfromance but will not provide scalability
Comment: We should "minimize", not "avoid", code changes.
Comment: minimize *architectural changes, NOT code changes
Comment: RDX proxy will :"improve the user experience while minimizing changes".
Comment: .. but not address issues with "database read performance".
Comment: A. Use Amazon ElastiCache in front of the database. Explanation: Amazon ElastiCache is a managed caching service that can be placed in front of the database to cache frequently accessed data. By caching the most common queries, it can significantly reduce the load on the database, leading to faster response times and an improved user experience. This solution minimizes changes to the existing architecture because it doesn't require modifications to the application's core logic or database schema. Instead, it optimizes performance by reducing the need for repetitive database reads. ElastiCache supports both Redis and Memcached, which are widely used for caching in web applications.
Comment: A for sure
Comment: answer should be B
Comment: Not B because this can help with connection management and improve scalability and availability but won't directly address read performance issues caused by high read traffic.
Comment: Another vague question from AWS: I would prefer A over B
Comment: A Caching frequently accessed data: ElastiCache can be used to reduce the load on your database by caching frequently accessed data. This can improve application performance and reduce the number of read queries to your database. Real-time applications: If your application requires real-time data processing, ElastiCache can help. Since it provides sub-millisecond response times, it can be used to power applications like gaming leaderboards, chat applications, and real-time analytics.
Comment: ask is - minimum changes. RDS Proxy is a feature of Amazon RDS. This would be easiest option to try.
Comment: Elasticache - reduce load due to read operations RDS proxy - reduce load due to lot of connections Here problem is read operations thus A is solution
Comment: I vote for Elasticache
Comment: B - "Use RDS Proxy between the application and the database." B because it improves the user experience while minimizing the changes. If A is used, you have to modify your application to get the data from the cache first, if it is not there, then get from db; and also to invalidate the cache if there is a db update.
Comment: https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html
Comment: RDS Proxy: It helps applications improve scalability and performance by managing database connections and pooling, which can significantly reduce the load on the database. By using RDS Proxy, you can offload connection management tasks from your application and optimize database access, thereby improving read performance without making significant changes to the application's architecture. Minimizing Changes: Implementing RDS Proxy does not require architectural changes to the application. It works as a proxy layer between the application and the RDS database, so the application code remains unchanged. This minimizes the effort and risk associated with making modifications to the application.
Comment: Selected Answer: A ElastiCache stores data in memorY RESOLVE THE READING Issue
Comment: A will be the best option regarding read performance and based on following link: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/creating-elasticache-cluster-with-RDS-settings.html
Comment: A. Use Amazon ElastiCache in front of the database: Caching frequently accessed data in ElastiCache can help reduce the load on the database and improve read performance. However, it's essential to note that while ElastiCache can significantly enhance read performance by serving frequently accessed data from memory, it might not entirely eliminate long delays and interruptions if the root cause is related to the database itself or if the caching strategy is not effectively implemented. B. Use RDS Proxy between the application and the database: Helps improve database connection management, reducing the number of open connections to the database and enhancing overall performance. RDS Proxy handles connection pooling, which means it can efficiently manage and reuse database connections, reducing the overhead of establishing new connections for each query. It supports features like read/write splitting, which directs read queries to read replicas, further distributing the load.
Comment: In this scenario, game scores are updated frequently so caching seems less useful than a proxy
Comment: ". A solutions architect needs to solve the problem with minimal changes to the existing web application." ABD all require major changes to the application. A: DynamoDB is NoSQL so big change B: Elasticache is a caching layer which require code change normally significant code change D: Redshift is analytics so not a solution
Comment: . While DynamoDB is a scalable NoSQL database, it requires changes to the application's data model and query patterns. B. ElastiCache is an in-memory data store that can improve query performance, but it is primarily used for caching rather than running complex queries. D. Redshift is a powerful data warehousing solution, but migrating the data and adapting the queries to Redshift's columnar architecture would require significant changes to the application and query logic. Therefore, option C is the most appropriate recommendation as it leverages read replicas in RDS to offload read-only query traffic from the primary database, allowing the business analysts to run their queries without impacting the performance of the web application. It provides a scalable and efficient solution with minimal changes to the existing web application.
Comment: C. Create a read replica of the primary database and have the business analysts run their queries
Comment: A. While DynamoDB is a scalable NoSQL database, it requires changes to the application's data model and query patterns. B. ElastiCache is an in-memory data store that can improve query performance, but it is primarily used for caching rather than running complex queries. D. Redshift is a powerful data warehousing solution, but migrating the data and adapting the queries to Redshift's columnar architecture would require significant changes to the application and query logic. Therefore, option C is the most appropriate recommendation as it leverages read replicas in RDS to offload read-only query traffic from the primary database, allowing the business analysts to run their queries without impacting the performance of the web application. It provides a scalable and efficient solution with minimal changes to the existing web application.
Comment: C, no doubt.
Comment: C is correct answer
Comment: C. Create a read replica of the primary database and have the business analysts run their queries. Creating a read replica of the primary RDS database will offload the read-only SQL queries from the primary database, which will help to improve the performance of the web application. Read replicas are exact copies of the primary database that can be used to handle read-only traffic, which will reduce the load on the primary database and improve the performance of the web application. This solution can be implemented with minimal changes to the existing web application, as the business analysts can continue to run their queries on the read replica without modifying the code.
Comment: Create a read replica of the primary database and have the business analysts run their queries.
Comment: here keyword is "before" "the data is encrypted at rest before the data is uploaded to the S3 buckets."
Comment: A I believe the question is crafted to cause some confusion. At the same time it is simple to answer, since client side encryption answers the the requirements.
Comment: Answer is A. Encrypt it first before uploading to S3.
Comment: I think the many votes for A are caused by misunderstanding the wording as "Ensure that the data is encrypted at rest before the data is uploaded" But that doesn't make sense, it means "Ensure that the data is encrypted at rest before the data is uploaded" So, before you allow people to upload data, make sure that it gets encrypted.
Comment: On second thought, C would not enforce encryption in transit. Thus must be A indeed.
Comment: For a moment I bought into your reasoning for C assuming that maybe the question is missing some grammar construct but realised that C does not really solve the encryption in transit issue like I originally thought. BUT good work!
Comment: BCD, data not yet encrypted before landing on S3 bucket
Comment: HTTPs would encrypt in transe, SSE3 managed keys fulfills requirement for at rest. This is an aws exam, not a best practices exam.
Comment: No. HTTPS is not enough for encryption in transit when it comes to S3. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html "Client-side encryption is the act of encrypting your data locally to help ensure its security in transit and at rest. "
Comment: Its_SaKar
Comment: Ans is B - Server-Side Encryption (SSE): ensure data is encrypted at rest and also Encryption in Transit: When you upload data to Amazon S3 using standard HTTPS requests.
Comment: Use client-side encryption to encrypt the data that is being uploaded to the S3 buckets
Comment: A. Use client-side encryption to encrypt the data that is being uploaded to the S3 buckets.
Comment: A. Use client-side encryption to encrypt the data that is being uploaded to the S3 buckets.
Comment: data must be encrypted before uploaded , which means the client need to do it before uploading the data to S3
Comment: A, would meet requirements.
Comment: Because the data must be encrypted while in transit
Comment: A is correct IMO
Comment: https://www.examtopics.com/discussions/amazon/view/53840-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: A. Use client-side encryption to encrypt the data that is being uploaded to the S3 buckets.
Comment: GOOD LUCK EVERYONE :) YOU CAN DO THIS
Comment: C is correct. Goodluck everybody!
Comment: Configuring scheduled scaling actions allows the Auto Scaling group to scale up to the desired capacity at a scheduled time (1 AM in this case) when the batch jobs start. This ensures the desired compute capacity is reached immediately. The Auto Scaling group can then scale down based on metrics after the batch jobs complete.
Comment: The time is given, use scheduled for optimal cost
Comment: just scheduled my exam :)
Comment: Reached here ! Did anyone schedule the real exam now ? How was it ?
Comment: Thanks to everyone who contributed with answers :)
Comment: C. I'm here at the end, leaving this here for posterity sake 02/01/2023.
Comment: GL ALL!
Comment: https://www.examtopics.com/discussions/amazon/view/27868-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: C. Configure scheduled scaling to scale up to the desired compute level. By configuring scheduled scaling, the solutions architect can set the Auto Scaling group to automatically scale up to the desired compute level at a specific time (1AM) when the batch job starts and then automatically scale down after the job is complete. This will allow the desired EC2 capacity to be reached quickly and also help in reducing the cost.
Comment: Configure scheduled scaling to scale up to the desired compute level.
Comment: predictable = schedule scaling
Comment: Configuring caching based on the language of the viewer If you want CloudFront to cache different versions of your objects based on the language specified in the request, configure CloudFront to forward the Accept-Language header to your origin. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html
Comment: B If you want CloudFront to cache different versions of your objects based on the language specified in the request, configure CloudFront to forward the Accept-Language header to your origin. If you want CloudFront to cache different versions of your objects based on the country that the request came from, configure CloudFront to forward the CloudFront-Viewer-Country header to your origin. CloudFront automatically converts the IP address that the request came from into a two-letter country code. For an easy-to-use list of country codes, sortable by code and by country name, see the Wikipedia entry ISO 3166-1 alpha-2.
Comment: Isn't CloudFront for static websites though? Question specifically states the content is dynamic
Comment: Cloudfront serves for both static and dynamic. If it was just static,then you can consider AWS S3.
Comment: By caching content based on the Accept-Language request header, CloudFront can serve the appropriate version of the website to users based on their language preferences. This solution allows the company to improve the website's performance for users around the world without having to recreate the existing architecture in multiple Regions.
Comment: CloudFront allows you to customize cache behavior based on various request headers. By setting the cache behavior to cache based on the Accept-Language request header, CloudFront can store and serve language-specific versions of the website content, reducing the need to repeatedly fetch the content from the ALB for users with the same language preference.
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-language
Comment: B is correct
Comment: I think it's b
Comment: B is the correct answer
Comment: Note: The difference between pilot light and warm standby can sometimes be difficult to understand. Both include an environment in your DR Region with copies of your primary Region assets. The distinction is that pilot light cannot process requests without additional action taken first, whereas warm standby can handle traffic (at reduced capacity levels) immediately. The pilot light approach requires you to “turn on” servers, possibly deploy additional (non-core) infrastructure, and scale up, whereas warm standby only requires you to scale up (everything is already deployed and running). Use your RTO and RPO needs to help you choose between these approaches. https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
Comment: Option A is incorrect because while Amazon Aurora global database is a good solution for disaster recovery, pilot light deployment provides only a minimalistic setup and would require manual intervention to make the DR Region fully operational, which increases the recovery time. Option B is a better choice than Option A as it provides a warm standby deployment, which is an automated and more scalable setup than pilot light deployment. In this setup, the database is replicated to the DR Region, and the standby instance can be brought up quickly in case of a disaster. Option C is incorrect because Multi-AZ DB instances provide high availability, not disaster recovery. Option D is a good choice for high availability, but it does not meet the requirement for DR in a different region with the least possible latency.
Comment: B: Warm Standby is better when it comes to LOWEST RTO. https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
Comment: "Different Region" rules out C and D ("Multi-AZ" is within a region) "Run at reduced capacity" = warm standby (while "pilot light" means that DR resources are shut down and are started manually in case of failover)
Comment: The warm standby approach involves ensuring that there is a scaled down, but fully functional, copy of your production environment in another Region. With the pilot light approach, you replicate your data from one Region to another and provision a copy of your core workload infrastructure. Resources required to support data replication and backup, such as databases and object storage, are always on. Other elements, such as application servers, are loaded with application code and configurations, but are "switched off".
Comment: An Amazon Aurora global database with a warm standby deployment provides continuous replication from one AWS Region to another, keeping the DR database up-to-date with minimal latency.
Comment: In a Pilot Light scenario, only an EC2 Instance and a DB may be running. In Warm Standby, however, everything is running — in a much smaller capacity. This means the load balancer, gateways, databases, all subnets, and everything else are ready to go on a moment's notice. with reference to below statement Option B is a better choice than Option A. "The remaining infrastructure in the DR Region needs to run at reduced capacity and must be able to scale up if necessary".
Comment: should be D.
Comment: No, my friend. The question asks for deployment in another Region. Hence, it cannot be C or D. The answer is B because is Global (different regions) and Ward Standby has faster RTO than Pilot Light.
Comment: "Multi-AZ" = multiple AZs in same region, but requirement is "a different AWS Region".
Comment: Guys, sorry but I don't really have time to deepdive as my exam is soon. Based on chatGPT and my previous study the answer should be B "Create Amazon Machine Images (AMIs) to back up the EC2 instances. Copy the AMIs to a secondary AWS Region. Automate infrastructure deployment in the secondary Region by using AWS CloudFormation," would likely be the most suitable solution for the given requirements. This option allows for the creation of Amazon Machine Images (AMIs) to back up the EC2 instances, which can then be copied to a secondary AWS region to provide disaster recovery capabilities. The infrastructure deployment in the secondary region can be automated using AWS CloudFormation, which can help to reduce the amount of time and resources needed for deployment and management.
Comment: please how do you use chatGPT to study for these questions?
Comment: Option B would be the most operationally efficient solution for implementing a DR solution for the application, meeting the requirement of an RTO of less than 4 hours and using the fewest possible AWS resources during normal operations. By creating Amazon Machine Images (AMIs) to back up the EC2 instances and copying them to a secondary AWS Region, the company can ensure that they have a reliable backup in the event of a disaster. By using AWS CloudFormation to automate infrastructure deployment in the secondary Region, the company can minimize the amount of time and effort required to set up the DR solution.
Comment: OPtion E : Automate infrastructure deployment in the secondary Region by using terraform and ditch AWS CloudFormation 😬🤪.
Comment: A is not "most operationally efficient" C and D do not meet the "use the fewest possible AWS resources during normal operations" requirement
Comment: Option D suggests launching EC2 instances in a secondary Availability Zone (AZ), but AZs are not separate AWS Regions. While it provides high availability within a Region, it doesn't offer geographic redundancy, which is essential for disaster recovery.
Comment: needs to use the fewest possible AWS resources during normal operations = backup & restore
Comment: Create Amazon Machine Images (AMIs) to back up the EC2 instances. Copy the AMIs to a secondary AWS Region. Automate infrastructure deployment in the secondary Region by using AWS CloudFormation
Comment: B SHOULD BE RIGHT
Comment: Option A: Add complexity and management overhead. Option B: Creating AMIs for backup and using AWS CloudFormation for infrastructure deployment in the secondary Region is a more streamlined and automated approach. CloudFormation allows you to define and provision resources in a declarative manner, making it easier to maintain and update your infrastructure. This solution is more operationally efficient compared to Option A. Option C: could be expensive and not fully aligned with the requirement of using the fewest possible AWS resources during normal operations. Option D: might not be sufficient for meeting the DR requirements, as Availability Zones are still within the same AWS Region and might be subject to the same regional-level failures.
Comment: Please I would really appreciate clarification with this question. The community has voted 100% that the right answer is B. However, option D is shown to be the correct answer. So, who sets the correct answer? Which one should new comers like myself believe? the community's or the other (which am guessing is set by the moderators???) Please help.
Comment: From Examtopics support: In very few cases a conflict is raised between the provided and most-voted answers. In case of conflict between the provided & most voted answers, we suggest our customers rely on the most voted answers and consider them most correct.
Comment: C may satisfy the requirement of using the fewest possible AWS resources during normal operations, it may not be the most operationally efficient or cost-effective solution in the long term.
Comment: So Weird , they have product for this > Elastic Disaster Recovery , but option is not given .
Comment: https://docs.aws.amazon.com/zh_cn/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#backup-and-restore
Comment: the answer should be B --->recovery time objective (RTO) of less than 4 hours. https://docs.aws.amazon.com/zh_cn/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#backup-and-restore
Comment: At first, I thought the answer is A. But it is C. It seems that there is no information in the question about CPU or Memory usage. So, we might think the answer is A. why? because what we need is to have the required (desired) number of instances. It already has scheduled scaling that works well in this scenario. Scale down after working hours and scale up in working hours. So, it just needs to adjust the desired number to start from 20 instances. But here is the point it shows A is WRONG!!! If it started with desired 20 instances, it will keep it for the whole day. What if the load is reduced? We do not need to keep the 20 instances always. That 20 is the MAXIMUM number we need, no the DESIRE number. So it is against COST that is the main objective of this question. So, the answer is C
Comment: There is no cooldown period in target tracking, but warm-up time.
Comment: There is a cooldown period in the auto-scaling group, which helps 'keeping costs to a minimum' as instances would be removed sooner.
Comment: If it stars with 20 instances it will not keep it all day. It will scale down based on demand. The scheduled action in Option A simply ensures that there are enough instances running to handle the increased traffic when the day begins, while still allowing the Auto Scaling group to scale up or down based on demand during the rest of the day. https://docs.aws.amazon.com/autoscaling/ec2/userguide/scale-your-group.html
Comment: This is right, setting desired capacity doesn't turn off autoscaling policies
Comment: From what I can tell, you must specify an end time, or else it will run indefinitly. So I think A would be right, if they specified an end time. Otherwise C is more cost effective https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html
Comment: C. Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period. Here's the reasoning: Target Tracking Scaling Policy: With a target tracking scaling policy, you can set a target value for a specific metric, such as CPU utilization. The Auto Scaling group then adjusts the capacity to maintain that target. Lower CPU Threshold: By triggering the target tracking action at a lower CPU threshold, the Auto Scaling group can proactively add instances when the workload increases, helping to address the slowness at the beginning of the day. Decrease Cooldown Period: Reducing the cooldown period allows the Auto Scaling group to scale in and out more rapidly, making adjustments quicker in response to changing demand.
Comment: Options A and D involve scheduled actions, which are time-based and may not be as responsive to immediate changes in demand. They also do not dynamically respond to varying workloads.
Comment: Question is about cost effectiveness hence Use target tracking scaling policies to maintain a specific metric, such as CPU utilization or request count per target. This allows the Auto Scaling group to dynamically adjust the number of instances based on real-time demand. We do not need to have 20 instances up and running during start of the day.
Comment: Not C because: target tracking scaling attempts to maintain a target metric (like average CPU utilization). While more responsive, it would still react to increased load rather than pre-scaling. The initial slow period would persist as the scaling reacts to the increased demand rather than anticipating it.
Comment: A for sure.
Comment: Answer is A. Makes more sense to me.
Comment: A is not cost effective, it would set the number of instances to maximum even before the first employee arrives. D is not cost effective, it would cause the permanent use of 20 instances B could almost work, but if you configure small steps then it scales too slowly in the morning; if you configure big steps (like "add 8 instances at a time") it would scale in the morning but not be cost-efficient during the day. C would address the requirement, it would scale to meet a certain CPU utilization. Decreasing the cooldown period (which is not possible for the scaling policy itself but for the auto-scaling group) would help 'keeping costs to a minimum'.
Comment: The question 369 is exactly the same problem, Since a scheduled scaling doesn't disable the autoscaling later in the day the A works perfectly well.
Comment: A. since only a boot storm issue at 9am and settle down in mid morning, 20 instance is enough to support the workload NOT C. Reduce threshold to trigger (lets say 50% from 80% utilization) and lower cool down period, will still take time to ramp up to max 20 instance.
Comment: How would scaling up to the maximum number of instances "keep costs to a minimum"?
Comment: I would go with A. Autoscaling is still there and the problem is clearly in morning.
Comment: WOuld not keep costs to a minimum
Comment: My mistake, I should have chosen c. A lower threshold can expand in advance, and lowering cooling can increase the expansion frequency.
Comment: I choose option A because the root of the problem is the inability of the scaling speed in the morning to meet the demand, rather than what criteria to use for scaling.
Comment: How would scaling up to the maximum number of instances "keep costs to a minimum"?
Comment: To keep costs to a minimum target tracking is the best option. For example the scaling metric is the average CPU utilization of the EC2 auto scaling instances, and their average during the day should always be 80%. When CloudWatch detects that the average CPU utilization is beyond 80% at start of day, it will trigger the target tracking policy to scale out the auto scaling group to meet this target utilization. Once everything is settled and the average CPU utilization has gone below 80% at night, another scale in action will kick in and reduce the number of auto scaling instances in the auto scaling group.
Comment: Option C is best
Comment: I am going A based on it stating upto 20 so you already know what they maximum they use which is n a sense consistent. however i can see why people have put C. I think they need more clarification on the questions.
Comment: How would scaling up to the maximum number of instances "keep costs to a minimum"?
Comment: A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.
Comment: How would scaling up to the maximum number of instances "keep costs to a minimum"?
Comment: CHATGPT says Answers is A A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.
Comment: Scaling Out: In the morning when you schedule the AWS EC2 scaling to have a minimum and maximum of 20 instances, if the load on your application increases beyond the current number of instances, AWS Auto Scaling will automatically launch new instances to meet the demand up to the maximum of 20 instances. Scaling In: As the load on your application decreases in the afternoon or night, AWS Auto Scaling will continuously monitor the health and load of your instances. If the instances are underutilized and can be terminated without affecting your application's performance, AWS Auto Scaling will automatically scale in by terminating excess instances, Why not D? If you specify the min instance, AWS will always keep the minimum number of instances (20 in this case) running.
Comment: A) Configure storage Auto Scaling on the RDS for Oracle instance. = Makes sense. With RDS Storage Auto Scaling, you simply set your desired maximum storage limit, and Auto Scaling takes care of the rest. B) Migrate the database to Amazon Aurora to use Auto Scaling storage. = Scenario specifies application's data layer uses Oracle-specific PL/SQL functions. This rules out migration to Aurora. C) Configure an alarm on the RDS for Oracle instance for low free storage space. = You could do this but what does it fix? Nothing. The CW notification isn't going to trigger anything. D) Configure the Auto Scaling group to use the average CPU as the scaling metric. = Makes sense. The CPU utilization is the precursor to the storage outage. When the ec2 instances are overloaded, the RDS instance storage hits its limits, too.
Comment: Nicely Explained.
Comment: B mean db migration and only oracle specfic commands are allowed C is just notification not High avalibilty Now the toss up is between D and E since D is measuring CPU % and E is measuring memory and the question states "This is causing the EC2 instances to become overloaded and the RDS instance to run out of storage" i will err on the side of option E
Comment: To ensure the system can automatically scale for the increased traffic, you can take the following steps: A. Configure storage Auto Scaling on the RDS for Oracle instance. By enabling storage Auto Scaling on the RDS instance, you ensure that additional storage is provisioned automatically when the existing storage reaches capacity. This helps prevent the RDS instance from running out of storage due to increased traffic and data growth. C. Configure an alarm on the RDS for Oracle instance for low free storage space. Setting up an alarm for low free storage space on the RDS instance allows you to receive notifications when the storage capacity is approaching its limits. This proactive monitoring helps you take necessary actions, such as adding more storage or scaling resources, before it affects the application's performance.
Comment: B is not possible because the application "uses Oracle-specific PL/SQL functions" C does not meet the "automatically scale" requirement E would require an agent on the hosts which we might not have, plus CPU is a better indicator than memory
Comment: A. Configure storage Auto Scaling on the RDS for Oracle instance. This option allows the RDS instance to automatically scale its storage based on the actual storage usage, ensuring that you don't run out of storage. D. Configure the Auto Scaling group to use the average CPU as the scaling metric. By using CPU utilization as a scaling metric, the Auto Scaling group can dynamically adjust the number of EC2 instances based on the application's demand. This helps in handling increased traffic and preventing overload on existing instances.
Comment: Option B (Migrate the database to Amazon Aurora): While Amazon Aurora provides benefits such as auto-scaling storage and high performance, it involves migrating from Oracle to Aurora, which might require application changes and data migration efforts. Option C (Configure an alarm on the RDS for Oracle instance for low free storage space): While it's good to have an alarm for low storage space, configuring storage Auto Scaling (Option A) is a more proactive solution that automatically adjusts storage before reaching a critical point. Option E (Configure the Auto Scaling group to use the average free memory as the scaling metric): While monitoring memory is important for application performance, CPU utilization is often a more direct and responsive metric for auto-scaling in many scenarios.
Comment: Configure storage Auto Scaling on the RDS for Oracle instance and Configure the Auto Scaling group to use the average CPU as the scaling metric to accommodate the increased traffic automatically.
Comment: Option B (Migrate the database to Amazon Aurora) may be a good long-term solution, but it involves database migration, which can be complex and time-consuming. For immediate scalability and to address the storage issue, configuring storage Auto Scaling on the existing RDS instance is a more immediate and straightforward solution. Option C (Configure an alarm on the RDS for Oracle instance for low free storage space) is useful for monitoring, but it doesn't proactively address the storage issue by automatically expanding storage as needed. Option E (Configure the Auto Scaling group to use the average free memory as the scaling metric) is less common as a scaling metric for EC2 instances compared to CPU utilization. While memory can be an important factor for application performance, CPU utilization is typically a more commonly used metric for scaling decisions. It also doesn't directly address the RDS storage issue.
Comment: A. By enabling storage Auto Scaling on the RDS for Oracle instance, it will automatically add more storage when the existing storage is running out, ensuring the application's data layer can handle the increased data storage requirements. D. By configuring the Auto Scaling group to use the average CPU utilization as the scaling metric, it can automatically add more EC2 instances to the Auto Scaling group when the CPU utilization exceeds a certain threshold. This will help handle the increased traffic and workload on the EC2 instances in the multi-tier application.
Comment: A. By enabling storage Auto Scaling on the RDS for Oracle instance, it will automatically add more storage when the existing storage is running out, ensuring the application's data layer can handle the increased data storage requirements. D. By configuring the Auto Scaling group to use the average CPU utilization as the scaling metric, it can automatically add more EC2 instances to the Auto Scaling group when the CPU utilization exceeds a certain threshold. This will help handle the increased traffic and workload on the EC2 instances in the multi-tier application.
Comment: These options will allow the system to scale both the compute tier (EC2 instances) and the data tier (RDS storage) automatically as traffic increases: A. Storage Auto Scaling will allow the RDS for Oracle instance to automatically increase its allocated storage when free storage space gets low. This ensures the database does not run out of capacity and can continue serving data to the application. D. Configuring the EC2 Auto Scaling group to scale based on average CPU utilization will allow it to launch additional instances automatically as traffic causes higher CPU levels across the instances. This scales the compute tier to handle increased demand.
Comment: Auto scaling storage RDS will ease storage issues and migrating Oracle Pl/Sql to Aurora is cumbersome. Also Aurora has auto storage scaling by default. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.Autoscaling
Comment: My answer is B & D... B. Migrate the database to Amazon Aurora to use Auto Scaling Storage. --- Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically. D. Configurate the Auto Scaling group to sue the average CPU as the scaling metric. -- Good choice. I believe either A & C or B & D options will work.
Comment: In this question, you have Oracle DB, and Amazon Aurora is for MySQL/PostgreSQL. A and D are the correct choices.
Comment: You can migrate Oracle PL/SQL to Aurora: https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-mysql-migration-playbook/chap-oracle-aurora-mysql.sql.html
Comment: I still think A is the answer, because RDS for Oracle auto scaling once enabled it will automatically adjust the storage capacity.
Comment: But the application "uses Oracle-specific PL/SQL functions".
Comment: a and d
Comment: A and D.
Comment: a and d
Comment: A and D
Comment: https://www.examtopics.com/discussions/amazon/view/46534-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Storage gateway is not used for storing content - only to transfer to the Cloud
Comment: A doesn't say "store content ON the gateway", it says "use AWS Storage Gateway for files" (which is the product) "to store the video content" [on S3].
Comment: Creating storage gateway for Files will mount S3 bucket as an NFS volume that can be shared among EC2 Instances in the same manner as EFS but more cost effectively.
Comment: There is no on-prem/non Aws infrastructure to create a gateway. Also, EFS+EBS is more expensive that EFS and S3. So D is the best option.
Comment: But how do you attach "an EBS volume" to all the servers, and how will you use the files on it then to serve customers.
Comment: D. Use Amazon S3 for storing the video content. Move the files temporarily over to an Amazon Elastic Block Store (Amazon EBS) volume attached to the server for processing. Amazon S3 (Simple Storage Service) is highly durable, scalable, and cost-effective for storing large volumes of data, such as video content. It offers lower storage costs compared to Amazon EFS and is suitable for storing large files like video content. For processing the video content, you can temporarily move the files from Amazon S3 to an Amazon EBS volume attached to the EC2 instances. This approach allows you to leverage the high-performance storage of Amazon EBS for processing, while still benefiting from the cost-effectiveness of Amazon S3 for long-term storage. Once processing is complete, you can remove the temporary files from the EBS volume and store the final results back in S3.
Comment: Answer is closer to the following principle and D is near impossible to implement: "Amazon S3 File Gateway – Amazon S3 File Gateway supports a file interface into Amazon Simple Storage Service (Amazon S3) and combines a service and a virtual software appliance. By using this combination, you can store and retrieve objects in Amazon S3 using industry-standard file protocols such as Network File System (NFS) and Server Message Block (SMB). You deploy the gateway into your on-premises environment as a virtual machine (VM) running on VMware ESXi, Microsoft Hyper-V, or Linux Kernel-based Virtual Machine (KVM), or as a hardware appliance that you order from your preferred reseller. You can also deploy the Storage Gateway VM in VMware Cloud on AWS, or as an AMI in Amazon EC2. The gateway provides access to objects in S3 as files or file share mount points. With a S3 File Gateway, you can do the following"
Comment: A is correct For D, how to move file from S3 to EBS temporarily????
Comment: I was initially going for D but EBS part makes no sense as it is not possible. Closest explanation of A is in this article: https://aws.amazon.com/blogs/storage/mounting-amazon-s3-to-an-amazon-ec2-instance-using-a-private-connection-to-s3-file-gateway/ A is missing a lot of key steps but D is just impossible. Maybe it's just the wording?
Comment: EFS is already used, why EBS is an option in the answer?
Comment: AWS Storage Gateway S3 file gateway can be setup on EC2 ( https://repost.aws/knowledge-center/file-gateway-ec2 ). It use local disks/EBS for caching data. D: Can be used too, using attached EBS volume to each EC2 instance to process files. If require single EBS volume to be attached to multiple EC2, then it is possible too if they are in the same Availability Zone -> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html. For me A and D both are possible, but expect AWS would like to select Storage GW
Comment: I agree. This documentation has convinced me. https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html
Comment: A would work, "Storage Gateway for files" can provide access to S3 (cheap) via NFS (what the clients are using now). It has some additional cost in addition to the S3 charges, but would still be way cheaper than EFS. B would work for a single server, but as it provides a volume via iSCSI, it could be mounted only to a single server - does not meet the 'multiple instances can access' requirement. C and D do not meet the 'multiple instances can access' requirement because EBS can't be easily attached to all servers at the same time.
Comment: And even if ignoring the 'multiple instances can access' requirement, D would be against WAF; for temporary storage you'd use instance storage, not EBS.
Comment: Storage gateway is intended for on-premises applications to access cloud storage, so A, B is out. The question explicitly states that the files are uploaded and stored in EFS, not S3, so D is not correct. The answer is C. The EFS storage costs 10 times more than EBS, so moving files to EBS after processing is the solution.
Comment: Answer D is correct. Storage gateway is not used for storing content - only to transfer to the Cloud
Comment: But how do you attach "an EBS volume" to all the servers, and how will you use the files on it then to serve customers? A doesn't say "store content ON the gateway", it says "use AWS Storage Gateway for files" (which is the product) "to store the video content" [on S3]. And to be exact, Storage Gateway is not "to transfer to the cloud" but to provide access to S3 storage via SMB or NFS.
Comment: Cost effective = Use Amazon S3 for storing the video content. Move the files temporarily over to an Amazon Elastic Block Store (Amazon EBS) volume attached to the server for processing
Comment: Amazon S3 provides low-cost object storage for storing large amounts of unstructured data like videos. The videos can be stored in S3 durably and reliably. For processing, the video files can be temporarily copied from S3 to an EBS volume attached to the EC2 instance. EBS provides low latency block storage for high performance video processing. Once processing is complete, the output can be stored back in S3.
Comment: The question doesn't give enough information. Well, quite a few AWS exam questions don't provide enough info. Ideally, A could be the best answer if it mentions S3 as the backend of storage gateway. Because if it doesn't mention S3 as the backend, that implies either Storage gateway as the storage(which is impossible) or continue using EFS(also impossible). D is not ideal, because it will introduce video download cost for downloading files from S3 to EBS temporary storage. But it is the best option we have.
Comment: A mentions "AWS Storage Gateway for files" which implies S3 as the backend storage. D does not meet the 'multiple instances can access for processing' requirement.
Comment: We are ditching EFS in favor of S3. So there is no longer simultaneous access happening. Whoever needs the file, downloads it from S3, process it on their EC2 instance and save it back to S3.
Comment: A more cost-effective storage solution for this scenario would be Amazon Simple Storage Service (Amazon S3). Amazon S3 is an object storage service that offers high scalability, durability, and availability at a lower cost compared to Amazon EFS. By using Amazon S3, you only pay for the storage you use, and it is typically more cost-efficient for scenarios where data is accessed less frequently, such as video storage for processing.
Comment: The result should be A. Amazon storage gateway has 4 types, S3 File Gateway, FSx file gateway, Type Gateway and Volume Gateway. If not specific reference file gateway should be default as S3 gateway, which sent file over to S3 the most cost effective storage in AWS. Why not D, the reason is last sentence, there are multiple EC2 servers for processing the video and EBS can only attach to 1 EC2 instance at a time, so if you use EBS, which mean for each EC2 instance you will have 1 EBS. This rule out D.
Comment: We can use multi-attach feature of EBS to attach one EBS volume to multiple Ec2 instances
Comment: AWS Storage Gateway = extend storage to onprem
Comment: Storage Gateway is a GATEWAY, it does not store anything. You could use the gateway as a cache for content actually in S3. Btw, A and B even say that Storage Gateway would "process the video content" ...
Comment: D: MOST cost-effective of these options = S3
Comment: Data in hierarchies : Amazon DynamoDB B. Use Amazon DynamoDB to store the employee data in hierarchies. Export the data to Amazon S3 every month. Sensitive Info: Amazon Macie E. Configure Amazon Macie for the AWS account. Integrate Macie with Amazon EventBridge to send monthly notifications through an Amazon Simple Notification Service (Amazon SNS) subscription.
Comment: Can someone please provide explanation why options "B" & "C" are the correct options?
Comment: C is half statement once event sent to Lambda what is next? Should send email right, but it does not say it.
Comment: B - because to store employee data in a hierarchical structured relationship. AmazonDB "...Schema flexibility lets DynamoDB store complex hierarchical data within a single item." E - because C omits the monthly email notifications resolved by using Amazon SNS. Just my take.
Comment: Why not C and D? Can anyone explain please.
Comment: A. Unload the data to Amazon S3 every month. doesnt make sense to empty the employee data from redshift monthly
Comment: B and E are the steps to meet all of the requirements.
Comment: Use Amazon DynamoDB to store the employee data in hierarchies. Export the data to Amazon S3 every month. Configure Amazon Macie for the AWS account. Integrate Macie with Amazon EventBridge to send monthly notifications through an Amazon Simple Notification Service (Amazon SNS) subscription.
Comment: B and E are the steps to meet all of the requirements. B meets the need to store hierarchical employee data in DynamoDB for low latency queries at high traffic. DynamoDB can handle the access patterns for hierarchical data. Exporting to S3 monthly provides an audit trail. E sets up Macie to analyze sensitive data and integrate with EventBridge to trigger monthly SNS notifications when financial data is present.
Comment: ]B. Amazon DynamoDB is a fully managed NoSQL database service that provides low-latency, high-performance storage for hierarchical data. It handle high-traffic queries and delivering fast responses to retrieve employee data efficiently. E. Amazon Macie is a service that uses machine learning to automatically discover, classify, and protect sensitive data in AWS. Integrating Macie with Amazon EventBridge allows you to receive events whenever any financial information is identified in the employee data. By using Amazon SNS, you can receive these notifications via email.
Comment: AE https://aws.amazon.com/es/blogs/big-data/query-hierarchical-data-models-within-amazon-redshift/
Comment: , the combination of DynamoDB for fast data queries, S3 for durable storage and backups, Macie for sensitive data monitoring, and EventBridge + SNS for email notifications satisfies all needs: fast query response, sensitive data protection, and monthly alerts. The solutions architect should implement DynamoDB with export to S3, and configure Macie with integration to send SNS email notifications.
Comment: Generally, for building a hierarchical relationship model, a graph database such as Amazon Neptune is a better choice. In some cases, however, DynamoDB is a better choice for hierarchical data modeling because of its flexibility, security, performance, and scale. https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-hierarchical-data-model/introduction.html
Comment: why Dynamo and not Redshift?
Comment: 1. Low latency - DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with single-digit millisecond latency. Redshift is a data warehouse solution optimized for complex analytical queries, so query latency would typically be higher. Since the requirements specify minimum latency for high-traffic queries, DynamoDB is better suited. 2. Scalability - DynamoDB is highly scalable, able to handle very high read and write throughput with no downtime. Redshift also scales, but may experience some downtime during rescale operations. For a high-traffic application, DynamoDB's scalability and availability are better matched.
Comment: 3. Hierarchical data - DynamoDB supports hierarchical (nested) data structures well in a NoSQL data model. Defining hierarchical employee data may be more complex in Redshift's columnar SQL data warehouse structure. DynamoDB is built around flexible data schemas that can represent complex relationships. 4. Data export - Both DynamoDB and Redshift allow exporting data to S3, so that requirement could be met with either service. However, overall DynamoDB is the better fit based on the points above regarding latency, scalability, and support for hierarchical data.
Comment: BE is crt 100%
Comment: B and E To send monthly email messages, an SNS service is required.
Comment: B and E
Comment: Option B mentions using Amazon S3 Glacier Flexible Retrieval, but DynamoDB doesn't natively support transitioning backups to Amazon S3 Glacier. Options C and D involve custom scripts and EventBridge rules, which add complexity and may not be as reliable or efficient as using AWS Backup for this purpose.
Comment: A for sure
Comment: https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html
Comment: Why B is wrong?
Comment: BCD, on-demand backup, manual work
Comment: https://aws.amazon.com/blogs/database/set-up-scheduled-backups-for-amazon-dynamodb-using-aws-backup/
Comment: A is right ans
Comment: All except A are "On-demand"
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html Using DynamoDB with AWS Backup, you can copy your on-demand backups across AWS accounts and Regions, add cost allocation tags to on-demand backups, and transition on-demand backups to cold storage for lower costs. To use these advanced features, you must opt in to AWS Backup.
Comment: "on demand" (manual) backup -> hell no
Comment: This solution satisfies the requirements in the following ways: • AWS Backup will automatically take full backups of the DynamoDB table on the schedule defined in the backup plan (the first of each month). • The lifecycle policy can transition backups to cold storage after 6 months, meeting that requirement. • Setting a 7-year retention period in the backup plan will ensure each backup is retained for 7 years as required. • AWS Backup manages the backup jobs and lifecycle policies, requiring no custom scripting or management.
Comment: Answer is A
Comment: Create an AWS Backup plan to back up the DynamoDB table on the first day of each month. Specify a lifecycle policy that transitions the backup to cold storage after 6 months. Set the retention period for each backup to 7 years
Comment: The correct Answer is A https://aws.amazon.com/blogs/database/set-up-scheduled-backups-for-amazon-dynamodb-using-aws-backup/
Comment: Its B. https://aws.amazon.com/blogs/database/set-up-scheduled-backups-for-amazon-dynamodb-using-aws-backup/
Comment: A is the answer
Comment: A is the answer.
Comment: A is the correct answe
Comment: A is the Answer can be used to create backup schedules and retention policies for DynamoDB tables
Comment: A. Create an AWS Backup plan to back up the DynamoDB table on the first day of each month. Specify a lifecycle policy that transitions the backup to cold storage after 6 months. Set the retention period for each backup to 7 years.
Comment: Answer is B - Quicksite creating data visualizations https://docs.aws.amazon.com/quicksight/latest/user/welcome.html
Comment: Data is in S3 -> Athena, not DynamoDB (thus A or B) Visualize -> QuickSight, not Glue (thus B or D)
Comment: Glue is meant to prepare and transform data for analytics, not to build visualizations. Hence A and C are out. Athena is used to analyze data stored in S3 and it is commonly used with QuickSight, thus B is the answer
Comment: Admin please remove my comment. That answer was for another question.
Comment: A & C combined make sense isn't it?
Comment: Why 'use queries in DynamoDB" when the data is in S3? And why Glue?
Comment: OptionB: Amazon Athena allows you to run standard SQL queries directly on the data stored in the S3 bucket. Amazon QuickSight is a business intelligence (BI) service that allows you to create interactive and visual dashboards to analyze data. You can connect Amazon QuickSight to Amazon Athena to visualize the results of your SQL queries from the CloudFront logs.
Comment: OptionB: Amazon Athena allows you to run standard SQL queries directly on the data stored in the S3 bucket. Amazon QuickSight is a business intelligence (BI) service that allows you to create interactive and visual dashboards to analyze data. You can connect Amazon QuickSight to Amazon Athena to visualize the results of your SQL queries from the CloudFront logs.
Comment: Answer is B
Comment: Athena and Quicksight. Glue is for ETL transformation
Comment: Answer is B Analysis on S3 = Athena Visualizations = Quicksight
Comment: Why the Hell A?
Comment: Why A! as far as I know Glue is not used for visualization
Comment: B because athena can be used to analyse data in s3 buckets and AWS quicksight is literally used to create visual representation of data
Comment: Using Athena to query the CloudFront logs in the S3 bucket and QuickSight to visualize the results is the best solution because it is cost-effective, scalable, and requires no infrastructure setup. It also provides a robust solution that enables the company to perform advanced analysis and build interactive visualizations without the need for a dedicated team of developers.
Comment: Yes B is the answer
Comment: Correct answer should be B.
Comment: B is correct
Comment: A: By using Multi-AZ deployment, the company can achieve an RPO of less than 1 second because the standby instance is always in sync with the primary instance, ensuring that data changes are continuously replicated.
Comment: Read Replicas: Read Replicas are asynchronous and support read scalability. It is uese to improve performance. Read Replicas can be in the same region or in a different region for disaster recovery purposes, but this involves manual intervention, which means Read Replicas do not provide automatic failover and requires DNS updates and application changes Multi-AZ: Multi-AZ maintains a synchronous standby replica of the primary instance in a different Availability Zone within the same region. Multi-AZ deployments provide high availability and automatic failover. Option A is better choice with respect to below statement, "the company sets a standard that requires a recovery point objective (RPO) of less than 1 second for all its production databases."
Comment: Correct answer is A
Comment: Same question old from SAA-C02 08.2021 https://www.examtopics.com/discussions/amazon/view/61072-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: C. Configure the DB instance in one Availability Zone, and create multiple read replicas in a separate Availability Zone. Here's why: Read Replicas: By configuring read replicas in a separate Availability Zone, you can leverage asynchronous replication to replicate data from the primary DB instance to the read replicas with minimal latency. This setup allows for near real-time data replication and can help achieve a low RPO. In contrast, Multi-AZ deployments (Option A) provide high availability by maintaining a standby replica but may not guarantee an RPO of less than 1 second due to synchronous replication and failover considerations. Options B and D are not directly related to achieving a low RPO for the databases.
Comment: I'm unsure with A, because the term RPO is not only applied to datacenter outages. Say, an application error corrupts the database, or an administrator accidentally overwrites all records. With answer A, Multi-AZ, these changes would be instantly copied to the replica. Only reason why A might still be correct is that the other answers don't make much more sense. B has nothing to do with RPO at all C could lose more than 1 second since read replicas are asynchronous D could be part of a solution but the CDC ask alone won't help
Comment: option A doesn't provide Data integrity only achieved in Option D using CDC.
Comment: Used for DR. Every single change is replicated in a standby AZ. If we lose the main AZ, (uses the same DNS name) standby becomes automatic failover and the new main DB.
Comment: Answer is A High availability = Multi AZ
Comment: My vote is A
Comment: Agree with A
Comment: Multi-AZ is a synchronous communication with the Master in "real time" and fail over will be almost instant.
Comment: correct is A
Comment: A should be correct
Comment: should be A
Comment: Correct Answer is A
Comment: Read the discussion, that's the whole point why examtopics picks the wrong answer. Follow most voted answer not examtopics answer
Comment: Configure the security group for the EC2 instances to only allow traffic that comes from the security group for the ALB
Comment: can anybody explains the question?
Comment: i don't even understand what the question is trying to ask
Comment: is just admins fault dont worry, he just made a mistake, because "C" doesnt make any sence
Comment: It's very confusing that the system marks C as correct.
Comment: This is B. Question already tells us they only want ONLY traffic from the ALB.
Comment: Answer is B
Comment: A security group acts as a firewall that controls the traffic allowed to and from the resources in your virtual private cloud (VPC).
Comment: Why C! another cazy answer , If i am concern about security why I would want to expose my EC2 to the public internet,not make sense at all, am I correct with this? I also go with B
Comment: B is the correct answer.
Comment: configure the security group for the EC2 instances to only allow traffic that comes from the security group for the ALB. This ensures that only the traffic originating from the ALB is allowed access to the EC2 instances in the private subnet, while denying any other traffic from other sources. The other options do not provide a suitable solution to meet the stated requirements.
Comment: B. Configure the security group for the EC2 instances to only allow traffic that comes from the security group for the ALB.
Comment: Amazon FSx for NetApp ONTAP provides shared storage between Linux and Windows file systems.
Comment: This solution satisfies the needs in the following ways: • Amazon EC2 provides a seamless migration path for the existing server-based applications without code changes. The simulation app can run on Linux EC2 instances and the visualization app on Windows EC2 instances. • Amazon FSx for NetApp ONTAP provides highly performant file storage that is accessible via both NFS and SMB. This allows the simulation app to write to NFS shares as currently designed, and the visualization app to access the same data via SMB. • FSx for NetApp ONTAP ensures the data is synchronized and up to date across the file systems. This addresses the data duplication issues of the current setup. • Resources can be scaled efficiently since EC2 and FSx provide scalable compute and storage on demand.
Comment: The other options would require more significant changes: A. Migrating to Lambda would require re-architecting both applications and not meet the requirement to avoid code changes. S3 does not provide file system access. B. While ECS could run the apps without code changes, FSx File Gateway only provides S3 or EFS storage, neither of which offer both NFS and SMB access. Data exchange would still be an issue. C. Using SQS for data exchange between EC2 instances would require code changes to implement a messaging system rather than a shared file system.
Comment: How does the data duplication issue get addressed on selecting D ?
Comment: Maybe I'm wrong, but I feel like the data is duplicated between the two types of EC2 instances. By using the FSX ONTAP will address this issue.
Comment: Because FSx for ONTAP provides THE SAME STORAGE via NFS and SMB. Duplication issue occured because Linux saved the files via NFS to one storage, then the data was copied to ANOTHER storage that shared it via SMB.
Comment: It is D but I think NetApp ONTAP is an oversell in this context. They just needed a FSx solution not a whole expensive managed service... ABC are a lot of change to the code so D is the only choice here anyway
Comment: Amazon FSx for NetApp ONTAP Fully managed service offering shared storage between Linux and Windows file systems (Multi & Single-AZ) up to petabytes datasets and 10+Gbps. - Allows Multi-protocol access to data using the (NFS), Server Message Block (SMB), and Internet Small Computer Systems Interface (iSCSI) protocols - Integrated with other AWS services (KMS, IAM, CloudTrail, amazon workspace) - ideal solution to migrate, back up, or burst your file-based applications from on-prem to AWS without application code change.
Comment: A would require code changes B might also require code changes, and "FSx File Gateway" provides SMB access (not NFS) C uses SQS which has no place here D can provide same storage via SMB and NFS
Comment: https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html
Comment: One of the use cases for Amazon FSx for NetApp ONTAP is when you need to move workloads running on NetApp or other NFS/SMB/iSCSI servers to AWS without modifying application code or how you manage data.
Comment: The key requirements are: Simulation app runs on Linux, outputs data to NFS Visualization app runs on Windows, requires SMB file system Migrate apps to AWS without code changes Eliminate data duplication and inefficient resource usage
Comment: For shared storage between Linux and windows you need to implement Amazon FSx for NetApp ONTAP
Comment: windows => FSX we didn't mention containers => can't be ECS
Comment: Amazon FSx for NetApp ONTAP is a fully managed service that provides shared file storage built on NetApp's popular ONTAP file system. It supports NFS, SMB, and iSCSI protocols2 and also allows multi-protocol access to the same data
Comment: Amazon FSx for NetApp ONTAP is a fully-managed shared storage service built on NetApp's popular ONTAP file system. Amazon FSx for NetApp ONTAP provides the popular features, performance, and APIs of ONTAP file systems with the agility, scalability, and simplicity of a fully managed AWS service, making it easier for customers to migrate on-premises applications that rely on NAS appliances to AWS. FSx for ONTAP file systems are similar to on-premises NetApp clusters. Within each file system that you create, you also create one or more storage virtual machines (SVMs). These are isolated file servers each with their own endpoints for NFS, SMB, and management access, as well as authentication (for both administration and end-user data access). In turn, each SVM has one or more volumes which store your data. https://aws.amazon.com/de/blogs/storage/getting-started-cloud-file-storage-with-amazon-fsx-for-netapp-ontap-using-netapp-management-tools/
Comment: B is correct I believe
Comment: "FSx File Gateway" is a gateway, and ECS would require code changes.
Comment: Answer is D
Comment: Cost Explorer looks at the usage pattern or history
Comment: Create a report in Cost Explorer and download the report
Comment: ° Cost Explorer is a AWS service that allows you to view, analyze, and manage your AWS costs and usage. It provides a variety of reports that you can use to track your costs, including a report of AWS billed items listed by user. ° Creating a report in Cost Explorer is a quick and easy way to get the information you need. You can customize the report to include the specific data you want, and you can download the report in a variety of formats, including CSV, Excel, and PDF.
Comment: This is trick question - You need to know the differences between the billing services.
Comment: Cost Explorer
Comment: Answer is B
Comment: Answer is B
Comment: Answer is B
Comment: Correct answer is B. https://aws.amazon.com/blogs/architecture/create-dynamic-contact-forms-for-s3-static-websites-using-aws-lambda-amazon-api-gateway-and-amazon-ses/
Comment: This solution is the most cost-efficient for the anticipated 100 monthly visits because: • API Gateway charges are based on API calls. With only 100 visits, charges would be minimal. • AWS Lambda provides compute time for the backend code in increments of 100ms, so charges would also be negligible for this workload. • Amazon SES is used only for sending emails from the submitted contact forms. SES has a generous free tier of 62,000 emails per month, so there would be no charges for sending the contact emails. • No EC2 instances or other infrastructure needs to be run and paid for.
Comment: Option D just made me laugh!
Comment: B is the most cost-effective solution for this use case. The key requirements are: Static website hosted on S3 Add a contact form with server-side processing Low traffic website (<100 visits per month.
Comment: why not C
Comment: Option C uses Lightsail which incurs charges even at low usage. Not cost effective for low traffic sites.
Comment: Also it has been decided that "the contact form will have dynamic server-side components ", thus "use client-side scripting to build the contact form" is not what has been asked for.
Comment: B would be cheaper than option D, Member only 100 site visits per month, so you are comparing API GW used 100 times a month with constantly running EC2...
Comment: Both api gateway and lambda are serverless so charges apply only on the 100 form submissions per month
Comment: After looking at cost of Workmail compared to SES - probably 'B' is better
Comment: Create a t2 micro Amazon EC2 instance. Deploy a LAMP (Linux Apache MySQL, PHP/Perl/Python) stack to host the webpage (free open-source). Use client-side scripting to build the contact form. Integrate the form with Amazon WorkMail. This solution will provide the company with the necessary components to host the contact form page and integrate it with Amazon WorkMail at the lowest cost. Option A requires the use of Amazon ECS, which is more expensive than EC2, and Option B requires the use of Amazon API Gateway, which is also more expensive than EC2. Option C requires the use of Amazon Lightsail, which is more expensive than EC2. https://aws.amazon.com/what-is/lamp-stack/
Comment: Option D uses EC2 which has a higher monthly cost than serverless options. LAMP stack adds complexity for a simple contact form.
Comment: 3 millon API Gateway == 3,50 USD (EE.UU. Este (Ohio)) Is more cheaper letter B https://aws.amazon.com/es/api-gateway/pricing/ https://aws.amazon.com/es/lambda/pricing/
Comment: It's B
Comment: B allows the company to create an API endpoint using AWS Lambda, which is a cost-effective and scalable solution for a contact form with low traffic. The backend can make a call to Amazon SES to send email notifications, which simplifies the process and reduces complexity.
Comment: it is B : https://aws.amazon.com/blogs/architecture/create-dynamic-contact-forms-for-s3-static-websites-using-aws-lambda-amazon-api-gateway-and-amazon-ses/
Comment: https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html Using AWS Lambda with Amazon API Gateway - AWS Lambda https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html https://aws.amazon.com/lambda/faqs/ AWS Lambda FAQs https://aws.amazon.com/lambda/faqs/
Comment: Option D uses EC2 which has a higher monthly cost than serverless options. LAMP stack adds complexity for a simple contact form.
Comment: Invalidate the CloudFront cache: The solutions architect should invalidate the CloudFront cache to ensure that the latest version of the website is being served to users.
Comment: C. Invalidate the CloudFront cache. Explanation: Invalidate the CloudFront cache to ensure that the latest updates from the Git repository are reflected on the static website. When updates are made to the website's Git repository and deployed to Amazon S3, the CloudFront cache may still be serving the old cached content to users. By invalidating the CloudFront cache, you're instructing CloudFront to fetch fresh content from the origin (Amazon S3) and serve it to users.
Comment: C for sure
Comment: Correct C, because Invalidating the CloudFront cache will force CloudFront to fetch the latest content from Amazon S3. Not B because not related to clear cache
Comment: Invalidate the CloudFront cache so that it can read the updated static page from S3.
Comment: C. Invalidate the CloudFront cache
Comment: C is the most reasonable cause, though the question is not well-written - "The static website uses a database backend." does not make a lot of sense to me.
Comment: Since the static website is hosted behind CloudFront, updates made to the S3 bucket will not be visible on the site until the CloudFront cache expires or is invalidated. By invalidating the CloudFront cache after deploying updates, the latest version in S3 will be pulled and the updates will then appear on the live site.
Comment: Isn't that C?
Comment: B should be the right one
Comment: We need to create an Cloudfront invalidation
Comment: C. Invalidate the CloudFront cache. Problem is the CF cache. After invalidating the CloudFront cache, CF will be forces to read the updated static page from the S3 and the S3 changes will start being visible.
Comment: It is B: A: Incorrect> FSx file Gateway designed for low latency and efficient access to in-cloud FSx for Windows File Server file shares from your on-premises facility. B: Correct> This solution will allow the company to host all three tiers on Amazon EC2 instances while using Amazon FSx for Windows File Server to provide Windows-based file sharing between the tiers. This will allow the company to use specific features of SQL Server, such as native backups and Data Quality Services, while sharing files for processing between the tiers. C: Incorrect> Currently, Amazon EFS supports the NFSv4.1 protocol and does not natively support the SMB protocol, and can't be used in Windows instances yet. D: Incorrect> Amazon EBS is a block-level storage solution that is typically used to store data at the operating system level, rather than for file sharing between servers.
Comment: RDS for SQL Backups: aren't Native MSSQL backups Instead RDS creates a storage volume snapshot of the instance, backing up the entire instance not just individual databases.
Comment: Not A - File Gateway is just a gateway, needs S3 too B - Yes Not C - RDS does not support the required features, and EFS does not provide SMB Not D - RDS does not support the required features, and EBS volume shared between tiers doesn't make sense
Comment: B. Host all three tiers on Amazon EC2 instances. Use Amazon FSx for Windows File Server for file sharing between the tiers.
Comment: The question mentions Microsoft = windows EFS is Linux
Comment: This design satisfies the needs in the following ways: • Running all tiers on EC2 allows using SQL Server on EC2 with its native features like backups and Data Quality Services. SQL Server cannot be run directly on RDS. • Amazon FSx for Windows File Server provides fully managed Windows file storage with SMB access. This allows sharing files between the Windows EC2 instances for all three tiers. • FSx for Windows File Server has high performance, so it can handle file sharing needs between the tiers.
Comment: The other options would not meet requirements: A. FSx File Gateway only provides access to S3 or EFS storage. It cannot be used directly for Windows file sharing. C. RDS cannot run SQL Server or its native tools. The database tier needs to run on EC2. D. EBS volumes can only be attached to a single EC2 instance. They cannot be shared between tiers for file exchanges.
Comment: No, there is RDS for SQL Server. https://aws.amazon.com/rds/sqlserver/
Comment: IO2 support multi-attach
Comment: Why not C?
Comment: Currently, Amazon EFS supports the NFSv4.1 protocol and does not natively support the SMB protocol, and can't be used in Windows instances yet.
Comment: Yup B . RDS will not work , Native Backup only to S3 , and Data Quality is not supported , so all EC2 . https://aws.amazon.com/premiumsupport/knowledge-center/native-backup-rds-sql-server/ and https://www.sqlserver-dba.com/2021/07/aws-rds-sql-server-limitations.html
Comment: After further research, I concur that the correct answer is B. Native Back up and Data Quality not supported on RDS for Ms SQL
Comment: C. Host the application tier and the business tier on Amazon EC2 instances. Host the database tier on Amazon RDS. Use Amazon Elastic File System (Amazon EFS) for file sharing between the tiers. This solution allows the company to use specific features of SQL Server such as native backups and Data Quality Services, by hosting the database tier on Amazon RDS. It also enables file sharing between the tiers using Amazon EFS, which is a fully managed, highly available, and scalable file system. Amazon EFS provides shared access to files across multiple instances, which is important for processing files between the tiers. Additionally, hosting the application and business tiers on Amazon EC2 instances provides the company with the flexibility to configure and manage the environment according to their requirements.
Comment: How are you gonna connect the EFS to windows based ??
Comment: Data Quality Services: If this feature is critical to your workload, consider choosing Amazon RDS Custom or Amazon EC2. https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html
Comment: Correct Answer: B
Comment: Since no code change is permitted, below choice makes sense for the unix server's file sharing: C. Create an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system on all web servers.
Comment: Rehost the application webservers on EC2 and Create an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system on all web servers.
Comment: Since no code change is permitted, below choice makes sense for the unix server's file sharing:
Comment: Since no code change is permitted, below choice makes sense for the unix server's file sharing:
Comment: C is correct.
Comment: This solution satisfies the needs in the following ways: • EFS provides a fully managed elastic network file system that can be mounted on multiple EC2 instances concurrently. • The EFS file system appears as a standard file system mount on the Linux web servers, requiring no application changes. The servers can access shared files as if they were on local storage. • EFS is highly available, durable, and scalable, providing a robust shared storage solution.
Comment: The other options would require modifying the application or do not provide a standard file system: A. S3 does not provide a standard file system mount or share. The application would need to be changed to access S3 storage. B. CloudFront is a content delivery network and caching service. It does not provide a file system mount or share and would require application changes. D. EBS volumes can only attach to a single EC2 instance. They cannot be mounted by multiple servers concurrently and do not provide a shared file system.
Comment: No application changes are allowed and EFS is compatible with Linux
Comment: C is the answer: Create an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system on all web servers. To meet the requirements of providing a shared file store for Linux-based web servers without making changes to the application, using an Amazon EFS file system is the best solution. Amazon EFS is a managed NFS file system service that provides shared access to files across multiple Linux-based instances, which makes it suitable for this use case. Amazon S3 is not ideal for this scenario since it is an object storage service and not a file system, and it requires additional tools or libraries to mount the S3 bucket as a file system. Amazon CloudFront can be used to improve content delivery performance but is not necessary for this requirement. Additionally, Amazon EBS volumes can only be mounted to one instance at a time, so it is not suitable for sharing files across multiple instances.
Comment: But what about aws ebs multi attach?
Comment: Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances. EBS General Purpose SSD (gp3) doesn't support Multi-Attach
Comment: This solution satisfies the needs in the most secure manner: • An IAM role provides temporary credentials to the Lambda function to access AWS resources. The function does not have persistent credentials. • The IAM policy grants least privilege access by specifying read access only to the specific S3 bucket needed. Access is not granted to all S3 buckets. • If the Lambda function is compromised, the attacker would only gain access to the one specified S3 bucket. They would not receive broad access to resources.
Comment: The other options are less secure: A. A bucket policy grants open access to a resource. It is a less granular way to provide access and grants more privilege than needed. C. Embedding access keys in code is extremely insecure and against best practices. The keys provide full access and are at major risk of compromise if the code leaks. D. Granting access to all S3 buckets provides far too much privilege if only one bucket needs access. It greatly expands the impact if compromised.
Comment: Has anyone passed this exam, choosing the wrong answers from ExamTopics? or what's the reason for the confusion???
Comment: B is correct.
Comment: Answer=B
Comment: B is correct.
Comment: you dont want to grant access to all S3 buckets (which is answer D) - only the one identified (so answer A)
Comment: B is only for one bucket and you want to use Role based security here.
Comment: C, it says MOST secure manner, so only to one bucket
Comment: https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html
Comment: This is the most secure and recommended way to provide an AWS Lambda function with access to an S3 bucket. It involves creating an IAM role that the Lambda function assumes, and attaching an IAM policy to the role that grants the necessary permissions to read from the S3 bucket.
Comment: B. Least of privilege
Comment: There is a little trap here, because in the way this question is asked, both B and C are true since we don't know if it's production or not. In a production environment C is absolutely forbidden and B is the good solution, we even have questions in this dump about this case. In a dev environment spot instances are good if you don't care about stability so C can be a good answer. Since this question is all about cost, let's go for the stingy rat solution, spot instances are cheaper, so C is correct.
Comment: By using a mix of On-Demand Instances and Spot Instances, the company can leverage the cost-effectiveness of Spot Instances for parts of their workload while ensuring the availability and reliability of On-Demand Instances for critical components. This approach allows for cost optimization without sacrificing performance or reliability.
Comment: On-demand + spot for additional capacity will save costs.
Comment: On-Demand.
Comment: Any one have dumps
Comment: It's about COST, not operational efficiency for this question :) C is correct
Comment: A mix of On-Demand Instances to handle baseline workload and Spot Instances to handle excess workload.
Comment: Exam topic is not free anymore. Anyone has free access ?
Comment: Free up to question 400, from 401 you have to pay
Comment: Now its upto question 250 and im pretty sure one day they will ask 100 dollars for all of 900 questions
Comment: for now though, I have still access.
Comment: By combining On-Demand Instances for steady-state workloads or critical components and Spot Instances for less critical or burstable workloads, you can achieve a balance between cost savings and performance. This strategy allows you to optimize costs without making a long-term commitment, as Spot Instances provide cost savings without the need for upfront payments or long-term contracts.
Comment: It's about COST, not operational efficiency for this question.
Comment: Autoscaling with ALB / scale up on demand using on demand and spot instance combination makes sense. Reserved will not fit the no-long term commitment clause.
Comment: Without commitment....Spot instances
Comment: If the company wants to optimize cost savings without making a long-term commitment, then using only On-Demand Instances may not be the most cost-effective option. Spot Instances can be significantly cheaper than On-Demand Instances, but they come with the risk of being interrupted if the Spot price increases above your bid price. If the company is willing to accept this risk, a mix of On-Demand Instances and Spot Instances may be the best option to optimize cost savings while maintaining the desired level of scalability. However, if the company wants the most predictable pricing and does not want to risk instance interruption, then using only On-Demand Instances is a good choice. It ultimately depends on the company's priorities and risk tolerance.
Comment: First, the question is about cost, cost, cost. Second, answer C is "a mix of on-demand and spot instances"; they could still use on-demand if spot is not available.
Comment: It's about COST, not operational efficiency for this question.
Comment: Should be C
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html
Comment: C - WEB apps , mostly Stateless , and ASG support OnDemand and Spot mix , in fact , you can prioritize to have Ondemand , before it uses Spot > https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-spot-instances.html
Comment: I thought that option A was totally wrong, because the question mentions "HTTP client does not support cookies". However it is right, along with option B. Check the link bellow, first paragraph. https://aws.amazon.com/blogs/media/secure-content-using-cloudfront-functions/
Comment: Plus, Customers can choose to use either one or both, depending on the use case. Thanks for this share !
Comment: Thanks for this! What a tricky question. If the client doesn't support cookies, THEN they use the signed S3 Urls.
Comment: LOL, like the old question, in my hand I have 2 coins, and they equal 15 cents, one of them is not a nickel. What are the coins
Comment: B. Signed URLs - This method allows the media company to control who can access the video content by creating a time-limited URL with a cryptographic signature. This URL can be distributed to the users who are unable to change the hardcoded URLs they are using for access, and they can access the content without needing to support cookies. D. JSON Web Token (JWT) - This method allows the media company to control who can access the video content by creating a secure token that contains user authentication and authorization information. This token can be distributed to the users who are using a custom HTTP client that does not support cookies. The users can include this token in their requests to access the content without needing to support cookies. Therefore, options B and D are the correct answers. Option A (Signed cookies) would not work for users who are using a custom HTTP client that does not support cookies. Option C (AWS AppSync) is not relevant to the requirement of securing video content. Option E (AWS Secrets Manager) is a service used for storing and retrieving secrets, which is not relevant to the requirement of securing video content.
Comment: This is the response of chatgpt isnt it ? Pay attention ! it doesn't always give the right answer
Comment: So you want to 'distribute the signed URL to the users who are unable to change the hardcoded URL'?
Comment: B. Signed URLs: Signed URLs allow you to control access to your content in CloudFront by providing URLs that are valid only for a specified duration. This means users can access the content using the same URLs they have hardcoded, without the need for cookies or special client support. D. JSON Web Token (JWT): JSON Web Tokens (JWTs) can be used to control access to resources by embedding authentication and authorization information in the token itself. Users can include the JWT in the request headers, allowing access to be controlled without relying on cookies. This approach doesn't require changes to hardcoded URLs and can be integrated into custom HTTP clients.
Comment: a little tricky but you have to "control" access, ok dont support cookies, so put signed cookies.
Comment: so how many marks do you get if you get 1 wrong
Comment: If you have gotten this far and got THIS trick question right then you are going to make it! Good Luck!
Comment: 'SOME are using a client that does not support cookies' -> use signed URLs 'SOME are unable to change the hardcoded URLs' -> used signed cookies
Comment: Signed URLs and signed cookies are the most suitable options. They can effectively address the requirements of both users with custom HTTP clients and those with hardcoded URLs.
Comment: B & E - B. Signed URLs: This allows you to generate time-limited URLs with a signature that grants temporary access to specific resources in your S3 bucket. It doesn't rely on cookies and can be generated for users without requiring any changes to their HTTP client or hardcoded URLs. This method provides fine-grained control over access to your content. E. AWS Secrets Manager: While AWS Secrets Manager can be useful for managing and rotating secrets, it is not directly related to securing S3 content in the context of the question. It's not one of the primary methods for securing access to S3 objects.
Comment: To secure streaming video content from Amazon CloudFront, two methods are available: signed cookies or signed URLs. Customers can choose to use either one or both, depending on the use case.
Comment: AB - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
Comment: B and D are the correct options for meeting the requirements with the least impact to users. Signed URLs allow access to individual objects in Amazon S3 for a specified time period without requiring cookies. This allows the custom HTTP client users to access content. JSON Web Tokens (JWT) allow users to get temporary access tokens that can be passed in requests. This allows users with hardcoded URLs to access content without updating URLs.
Comment: No good Signed cookies require client support and may impact users. AWS AppSync and Secrets Manager do not help address the specific access requirements. Good So Signed URLs and JWTs allow securing access to S3 content with minimal impact to users, meeting the requirements.
Comment: I understand why many users here are voting AB, but in my opinion BD is more correct. Using JWT or signed urls will work both for users that cannot use cookies or cannot change the url.
Comment: it's correct
Comment: These are the right answers!
Comment: "Some of the company's users" does not support cookies, then they'll use Signed URLs. "Some of the company's users" are unable to change the hardcoded URLs, then they'll use Signed cookies.
Comment: Signed cookies would allow the media company to authorize access to related content (like HLS video segments) with a single signature, minimizing implementation overhead. This works for users that can support cookies. Signed URLs would allow the media company to sign each URL individually to control access, supporting users that cannot use cookies. By embedding the signature in the URL, existing hardcoded URLs would not need to change.
Comment: C. AWS AppSync - This is for building data-driven apps with real-time and offline capabilities. It does not directly help with securing streaming content. D. JSON Web Token (JWT) - Although JWTs can be used for authorization, they would require the client to get a token and validate/check access on the server for each request. This does not work for hardcoded URLs and minimizes impact. E. AWS Secrets Manager - This service is for managing secrets, not for controlling access to resources. It would not meet the requirements.
Comment: Nicely put
Comment: OK, for B I did some research, https://docs.aws.amazon.com/glue/latest/dg/add-job-streaming.html "You can create streaming extract, transform, and load (ETL) jobs that run continuously, consume data from streaming sources like Amazon Kinesis Data Streams, Apache Kafka, and Amazon Managed Streaming for Apache Kafka (Amazon MSK). The jobs cleanse and transform the data, and then load the results into Amazon S3 data lakes or JDBC data stores."
Comment: But how can you transform data using kinesis data analytics ??
Comment: See https://aws.amazon.com/kinesis/data-analytics/faqs/?nc=sn&loc=6
Comment: Just because C is not going to work a DE use RDS so totally illogical A & B seem to have redundant streaming, transformation and query steps so not sure if these are the right choices but CDE are completely wrong anyway!
Comment: For A didn't know that Kinesis Analytics can transform the data as well: Amazon Kinesis Data Analytics provides built-in functions to filter, aggregate, and transform streaming data for advanced analytics. It processes streaming data with sub-second latencies, enabling you to analyze and respond to incoming data and streaming events in real time.
Comment: "Use SQL to query the transformed data" [which is in S3] requires Athena, thus D and E are out. DMS is nonsense here thus C is out.
Comment: why E is not right choise?
Comment: Because you can't "use the Amazon RDS query editor to query .. data from S3"
Comment: options A and B will meet these requirements.
Comment: A and B are correct. A uses Kinesis Data Streams for streaming, Kinesis Data Analytics for transformation, Kinesis Data Firehose for writing to S3, and Athena for SQL queries on S3 data. B uses Amazon MSK for streaming, AWS Glue for transformation and writing to S3, and Athena for SQL queries on S3 data.
Comment: Why E is incorrect?
Comment: "Use the Amazon RDS query editor to query the transformed data from Amazon S3." is not possible as RDS query editor is for RDS and not for S3
Comment: To transform real-time streaming data from multiple sources, write it to Amazon S3, and query the transformed data using SQL, the company can use the following solutions: Amazon Kinesis Data Streams, Amazon Kinesis Data Analytics, and Amazon Kinesis Data Firehose. The transformed data can be queried using Amazon Athena. Therefore, options A and E are the correct answers. Option A is correct because it uses Amazon Kinesis Data Streams to stream data from multiple sources, Amazon Kinesis Data Analytics to transform the data, and Amazon Kinesis Data Firehose to write the data to Amazon S3. Amazon Athena can be used to query the transformed data in Amazon S3. Option E is also correct because it uses Amazon Kinesis Data Streams to stream data from multiple sources, AWS Glue to transform the data, and Amazon Kinesis Data Firehose to write the data to Amazon S3. Amazon Athena can be used to query the transformed data in Amazon S3.
Comment: Amazon Athena is not in option E
Comment: DMS can move data from DBs to streaming services and cannot natively handle streaming data. Hence A.B makes sense. Also AWS Glue/ETL can handle MSK streaming https://docs.aws.amazon.com/glue/latest/dg/add-job-streaming.html.
Comment: The solutions that meet the requirements of streaming real-time data, transforming the data before writing to S3, and querying the transformed data using SQL are A and B. Option C: This option is not ideal for streaming real-time data as AWS DMS is not optimized for real-time data ingestion. Option D & E: These option are not recommended as the Amazon RDS query editor is not designed for querying data in S3, and it is not efficient for running complex queries.
Comment: The correct answers are options A & B
Comment: may Amazon RDS query editor to query the transformed data from Amazon S3 ? i don't think so, plz get link docs to that
Comment: Why not A & D?
Comment: may Amazon RDS query editor to query the transformed data from Amazon S3 ? i don't think so, plz get link docs to that
Comment: A and B
Comment: Answer is : A & B
Comment: The question states, "wants to maintain local access to all the data" This is storage gateway. Cached gateway stores only the frequently accessed data locally which is not what the problem statement asks for.
Comment: 1. The company wants to maintain local access to all the data. Only stored volumes keep the complete dataset on-premises, providing low-latency access. Cached volumes only cache a subset locally. 2. The company wants the data backed up on AWS. With stored volumes, periodic backups (snapshots) of the on-premises data are sent to S3, providing durable and scalable backup storage. 3. The company wants the data transfer to AWS to be automatic and secure. Storage Gateway provides an encrypted connection between the on-premises gateway and AWS storage. Backups to S3 are sent asynchronously and automatically based on the backup schedule configured.
Comment: The Volume Gateway runs in either a cached or stored mode. In the cached mode, your primary data is written to S3, while retaining your frequently accessed data locally in a cache for low-latency access. In the stored mode, your primary data is stored locally and your entire dataset is available for low-latency access while asynchronously backed up to AWS. https://aws.amazon.com/storagegateway/faqs/#:~:text=What%20is%20Volume%20Gateway%3F
Comment: @kruasan well explained
Comment: Ans = D https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html
Comment: D https://www.examtopics.com/discussions/amazon/view/43725-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: https://aws.amazon.com/storagegateway/faqs/#:~:text=In%20the%20cached%20mode%2C%20your,asynchronously%20backed%20up%20to%20AWS. In the cached mode, your primary data is written to S3, while retaining your frequently accessed data locally in a cache for low-latency access. In the stored mode, your primary data is stored locally and your entire dataset is available for low-latency access while asynchronously backed up to AWS.
Comment: S3 and DynamoDB are the only services with Gateway endpoint options
Comment: Set up a gateway VPC endpoint for Amazon S3 in the VPC.
Comment: The correct answer is B. Set up a gateway VPC endpoint for Amazon S3 in the VPC. A gateway VPC endpoint is a private way for Amazon EC2 instances in a VPC to access AWS services, such as Amazon S3, without having to go through the internet. This can help to improve security and performance.
Comment: Agree with B
Comment: ANSWER - B https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.htmlR B
Comment: B is correct
Comment: Bbbbbbbb
Comment: Actually this is what Macie is best used for.
Comment: "Akshually" bro go to sleep
Comment: Yes. That's the problem here, Macie is the recommended tool in such case, but you do not have it in the answers.
Comment: Macie is for identifying the PII data. Here it's much simpler because one of the apps need the PII data and other apps don't so you don't need to identify the PII data as you know it is already there. You just need to identify the app that needs the data which is not the best use case for Macie
Comment: B is the right answer and the proof is in this link. https://aws.amazon.com/blogs/aws/introducing-amazon-s3-object-lambda-use-your-code-to-process-data-as-it-is-being-retrieved-from-s3/
Comment: This is so wrong
Comment: But it matches the exact use case here.
Comment: Why do you think this is wrong?
Comment: I miss you Burugudystunstuguy....Man's been conistent with his answers
Comment: [GPT4] while S3 Object Lambda is a powerful tool for real-time data transformation, it is not the best fit for processing very large datasets due to Lambda's execution limits(15 min). Instead, preprocessing the data and storing it in separate S3 buckets for each applicatin's needs is a more operationally efficient solution for the scenario describes.
Comment: Because this is exactly what the AWS blog says. "When you store data in Amazon Simple Storage Service (Amazon S3), you can easily share it for use by multiple applications. However, each application has its own requirements and may need a different view of the data. For example, a dataset created by an e-commerce application may include personally identifiable information (PII) that is not needed when the same data is processed for analytics and should be redacted."
Comment: "Today, I'm very happy to announce the availability of S3 Object Lambda, a new capability that allows you to add your own code to process data retrieved from S3 before returning it to an application. S3 Object Lambda works with your existing applications and uses AWS Lambda functions to automatically process and transform your data as it is being retrieved from S3. The Lambda function is invoked inline with a standard S3 GET request, so you don't need to change your application code." https://aws.amazon.com/de/blogs/aws/introducing-amazon-s3-object-lambda-use-your-code-to-process-data-as-it-is-being-retrieved-from-s3/
Comment: B. Store the data in an Amazon S3 bucket. Process and transform the data by using S3 Object Lambda before returning the data to the requesting application. This solution allows you to use S3 Object Lambda to process and transform the data on-the-fly as it is requested by each application. S3 Object Lambda enables you to apply custom code to your data retrieval requests, allowing you to remove PII before returning the data to the requesting application. This eliminates the need to create and manage separate storage locations for each application, reducing operational overhead.
Comment: Why would you reprocess the data every time you request it when you can just filter it once and be done? Because of this I think A and B are highly inefficient, leaving us with C and D as options. Since S3 is better suited for Data Lakes, I think C is the answer.
Comment: Because this is exactly what the AWS blog says. "When you store data in Amazon Simple Storage Service (Amazon S3), you can easily share it for use by multiple applications. However, each application has its own requirements and may need a different view of the data. For example, a dataset created by an e-commerce application may include personally identifiable information (PII) that is not needed when the same data is processed for analytics and should be redacted. ... Today, I'm very happy to announce the availability of S3 Object Lambda, a new capability that allows you to add your own code to process data retrieved from S3 before returning it to an application. S3 Object Lambda works with your existing applications and uses AWS Lambda functions to automatically process and transform your data as it is being retrieved from S3."
Comment: Least operational overhead. The DevOps team is throwing this problem to the developers which is why C is not best.
Comment: Store the data in an Amazon S3 bucket and using S3 Object Lambda to process and transform the data before returning it to the requesting application. This approach allows the PII to be removed in real-time and without the need to create separate datasets or tables for each application.
Comment: @fruto123 and everyone that upvoted: Is it plausible that S3 Object Lambda can process terabytes of data in 60 seconds? The same link you shared states that the maximum duration for a Lambda function used by S3 Object Lambda is 60 seconds. Answer is A.
Comment: Chat GPT: Isn't just 60 seconds the maximum duration for a Lambda function used by S3 Object Lambda? How can it process terabytes of data in 60 seconds? You are correct that the maximum duration for a Lambda function used by S3 Object Lambda is 60 seconds. Given the time constraint, it is not feasible to process terabytes of data within a single Lambda function execution. S3 Object Lambda is designed for lightweight and real-time transformations rather than extensive processing of large datasets. To handle terabytes of data, you would typically need to implement a distributed processing solution using services like Amazon EMR, AWS Glue, or AWS Batch. These services are specifically designed to handle big data workloads and provide scalability and distributed processing capabilities. So, while S3 Object Lambda can be useful for lightweight processing tasks, it is not the appropriate tool for processing terabytes of data within the execution time limits of a Lambda function.
Comment: Terabyte is just the storage. Lambda only need to process which application request. Think like removing/scratching off your social security number before sharing your doc to a third party.
Comment: • Storing the raw data in S3 provides a durable, scalable data lake. S3 requires little ongoing management overhead. • S3 Object Lambda can be used to filter and process the data on retrieval transparently. This minimizes operational overhead by avoiding the need to preprocess and store multiple transformed copies of the data. • Only one copy of the data needs to be stored and maintained in S3. S3 Object Lambda will transform the data on read based on the requesting application. • No additional applications or proxies need to be developed and managed to handle the data transformation. S3 Object Lambda provides this functionality.
Comment: Option A requires developing and managing a proxy app layer to handle data transformation, adding overhead. Options C and D require preprocessing and storing multiple copies of the transformed data, adding storage and management overhead. Option B using S3 Object Lambda minimizes operational overhead by handling data transformation on read transparently using the native S3 functionality. Only one raw data copy is stored in S3, with no additional applications required.
Comment: https://aws.amazon.com/ko/blogs/korea/introducing-amazon-s3-object-lambda-use-your-code-to-process-data-as-it-is-being-retrieved-from-s3/
Comment: B is the correct answer. Amazon S3 Object Lambda allows you to add custom code to S3 GET requests, which means that you can modify the data before it is returned to the requesting application. In this case, you can use S3 Object Lambda to remove the PII before the data is returned to the two applications that do not need to process PII. This approach has the least operational overhead because it does not require creating separate datasets or proxy application layers, and it allows you to maintain a single copy of the data in an S3 bucket.
Comment: To meet the requirement of removing the PII before processing by two of the applications, it would be most efficient to use option B, which involves storing the data in an Amazon S3 bucket and using S3 Object Lambda to process and transform the data before returning it to the requesting application. This approach allows the PII to be removed in real-time and without the need to create separate datasets or tables for each application. S3 Object Lambda can be configured to automatically remove PII from the data before it is sent to the non-PII processing applications. This solution provides a cost-effective and scalable way to meet the requirement with the least operational overhead.
Comment: I think it is B.
Comment: Looks like C is the correct answer
Comment: 10.0.1.0/32 and 192.168.1.0/32 are too small for VPC, and /32 network is only 1 host 192.168.0.0/24 is overlapping with existing VPC
Comment: • Option A (10.0.1.0/32) is invalid - a /32 CIDR prefix is a host route, not a VPC range. • Option B (192.168.0.0/24) overlaps the development VPC and so cannot be used. • Option C (192.168.1.0/32) is invalid - a /32 CIDR prefix is a host route, not a VPC range. • Option D (10.0.1.0/24) satisfies the non-overlapping CIDR requirement but is a larger block than needed. Since only two VPCs need to be peered, a /24 block provides more addresses than necessary.
Comment: In an Amazon VPC, the first four and the last IP address in each subnet are reserved for specific purposes, and they cannot be used for customer instances. Here's how the reserved addresses are typically allocated: Network Address (First IP): The first IP address (all zeros in the host portion) in a subnet is reserved as the network address. For example, if you have a subnet with a CIDR notation of 10.0.0.0/24, the network address would be 10.0.0.0. VPC Router (Second IP): The second IP address in the subnet is reserved for the VPC router. DNS Server (Third IP): The third IP address is reserved for the DNS server. Reserved for Future Use (Fourth IP): The fourth IP address is reserved for future use. Customer Instances (Fifth to Second-to-Last IP): The IP addresses from the fifth to the second-to-last IP address in the subnet are available for customer instances. Broadcast Address (Last IP): The last IP address (all ones in the host portion) in a subnet is reserved as the broadcast address, even though AWS does not support broadcast.
Comment: 10.0.0.0 - 10.255.255.255 (10/8 prefix): Example CIDR block: 10.0.0.0/16 172.16.0.0 - 172.31.255.255 (172.16/12 prefix): Example CIDR block: 172.31.0.0/16 192.168.0.0 - 192.168.255.255 (192.168/16 prefix): Example CIDR block: 192.168.0.0/20 Given that the development VPC already uses 192.168.0.0/24, we need to choose a non-overlapping CIDR block. The smallest valid CIDR block that meets the requirements is 192.168.1.0/24 (Option C).
Comment: A and C are host IP addresses. B is not possible because it's using the same subnet for the other team/department. We are left with D, which is the right answer.
Comment: 10.0.1.0/32 and 192.168.1.0/32 are too small for VPC, and /32 network is only 1 host 192.168.0.0/24 is overlapping with existing VPC
Comment: Definitely D. The only valid VPC CIDR block that does not overlap with the development VPC CIDR block among the options. The other 2 CIDR block options are too small.
Comment: D is correct.
Comment: D is the only correct answer
Comment: only one valid with no overlap
Comment: A process by elimination solution here. a CIDR value is the number of bits that are lockeed so 10.0.0.0/32 means no range.
Comment: Answer is D, 10.0.1.0/24.
Comment: Yes D is the answer
Comment: Definitely D. It is the only valid VPC CIDR block that does not overlap with the development VPC CIDR block among the options.
Comment: The allowed block size is between a /28 netmask and /16 netmask. The CIDR block must not overlap with any existing CIDR block that's associated with the VPC. https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html
Comment: Just create an auto scaling policy
Comment: I picked B.. I am not 100% sure..The application is deployed in 5 instances initially. What is the logic behind 2/3/6 ASG. Because utilization is 10%, we can set min 2? I know for sure I am not going to get this ASG question correct in the exam.
Comment: The correct answer is B. This solution will meet the requirements because it will: Automate the scalability of the application by using EC2 Auto Scaling. Optimize the cost of the architecture by only scaling the number of EC2 instances up when needed. Ensure that the application has enough CPU resources when surges occur by setting the target value of the target tracking scaling policy to 50%.
Comment: Wrong answers: Options A, C, and D are not the most appropriate solutions: Option A suggests creating a CloudWatch alarm to terminate an EC2 instance when CPU utilization is less than 20%. However, this approach does not ensure that the application will have enough CPU resources during surges, as it only terminates instances when CPU utilization is low, which may not meet the requirements. Option C suggests creating an Auto Scaling group without any specific scaling policies or configurations. This approach does not address the need for automated scaling based on CPU utilization, making it insufficient for the given requirements. Option D suggests using CloudWatch alarms to send notifications via Amazon SNS and manually adjusting the number of instances based on the received messages. This approach lacks automation and requires manual intervention, which does not optimize cost or meet the requirement of automated scalability. Therefore, Option B is the most appropriate solution in this case.
Comment: Explanation: Option B leverages EC2 Auto Scaling, which is designed to automatically adjust the number of instances based on specified metrics. By setting a target tracking scaling policy based on average CPU utilization, the Auto Scaling group can dynamically scale the number of instances to maintain the desired level of CPU resources. The minimum instances of 2 ensure a minimum baseline capacity, while the desired capacity of 3 ensures at least three instances are running even during normal traffic. The maximum instances of 6 cap the upper limit to control costs.
Comment: Auto Scaling group must have an AMI for it.
Comment: "After receiving the message, log in to decrease or increase the number of EC2 instances that are running" does surely not "automate the scalability".
Comment: how can we set max to 6 since the company is using 5 ec2 instance
Comment: In the scenario you provided, you're setting up an Auto Scaling group to manage the instances for you, and the settings (min 2, desired 3, max 6) are for the Auto Scaling group, not for your existing instances. When you integrate the instances into the Auto Scaling group, you are effectively moving from a fixed instance count to a dynamic one that can range from 2 to 6 based on the demand. The existing 5 instances can be included in the Auto Scaling group, but the group can reduce the number of instances if the load is low (to the minimum specified, which is 2 in this case) and can also add more instances (up to a maximum of 6) if the load increases.
Comment: Reasons: • An Auto Scaling group will automatically scale the EC2 instances to match changes in demand. This optimizes cost by only running as many instances as needed. • A target tracking scaling policy monitors the ASGAverageCPUUtilization metric and scales to keep the average CPU around the 50% target value. This ensures there are enough resources during CPU surges. • The ALB and target group are reused, so the application architecture does not change. The Auto Scaling group is associated to the existing load balancer setup. • A minimum of 2 and maximum of 6 instances provides the ability to scale between 3 and 6 instances as needed based on demand. • Costs are optimized by starting with only 3 instances (the desired capacity) and scaling up as needed. When CPU usage drops, instances are terminated to match the desired capacity.
Comment: Option A - terminates instances reactively based on low CPU and may not provide enough capacity during surges. Does not optimize cost. Option C - lacks a scaling policy so will not automatically adjust capacity based on changes in demand. Does not ensure enough resources during surges. Option D - requires manual intervention to scale capacity. Does not optimize cost or provide an automated solution.
Comment: as you dig down the question, they get more and more bogus with less and less votes
Comment: B is my vote
Comment: Based on the information given, the best solution is option"B". Autoscaling group with target tracking scaling policy with min 2 instances, desired capacity to 3, and the maximum instances to 6.
Comment: But the company is using only 5 EC2 Instances so how can we set maximum instance to 6.
Comment: "Create an EC2 Auto Scaling group" includes replacing your existing EC2 instances with a launch configuration that starts and stops instances automatically.
Comment: B is the correct solution because it allows for automatic scaling based on the average CPU utilization of the EC2 instances in the target group. With the use of a target tracking scaling policy based on the ASGAverageCPUUtilization metric, the EC2 Auto Scaling group can ensure that the target value of 50% is maintained while scaling the number of instances in the group up or down as needed. This will help ensure that the application has enough CPU resources during surges without overprovisioning, thus optimizing the cost of the architecture.
Comment: Should be B
Comment: A subnet must reside within a single Availability Zone. https://aws.amazon.com/vpc/faqs/#:~:text=Can%20a%20subnet%20span%20Availability,within%20a%20single%20Availability%20Zone.
Comment: a subnet only resides on a one AZ, it does not span to another AZ.
Comment: A subnet can't "Extend" across multiple AZs: B,D out HA = RDS Multi-AZ: A out C
Comment: An Auto Scaling group can span across two Availability Zones, where one subnet is created in each AZ. When creating an Auto Scaling group, you need to specify at least one subnet. You can add additional subnets later on, including subnets across multiple AZs. Auto Scaling will distribute instances evenly across the specified subnets to maintain availability and optimize performance. If one AZ becomes unavailable, instances can be launched in the other AZ. The associated load balancer should also span the same subnets/AZs as the Auto Scaling group. This allows traffic to be routed to instances in different subnets and AZs, increasing fault tolerance of the application.
Comment: Provision a subnet in each Availability Zone. Configure the Auto Scaling group to distribute the EC2 instances across both Availability Zones. Configure the DB instance for Multi-AZ deployment
Comment: This solution will ensure that the EC2 instances and the DB instance are not located in the same Availability Zone, which will improve the availability of the application.
Comment: D is completely wrong, because each subnet must reside entirely within one Availability Zone and cannot span zones. By launching AWS resources in separate Availability Zones, you can protect your applications from the failure of a single Availability Zone.
Comment: The key word here was extend.
Comment: This discards B and D: Subnet basics. Each subnet must reside entirely within one Availability Zone and cannot span zones. By launching AWS resources in separate Availability Zones, you can protect your applications from the failure of a single Availability Zone
Comment: a subnet is per AZ. a scaling group can span multiple AZs. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-availability-zone.html
Comment: I think D. Span the single subnet in both Availability Zones can access the DB instances in either zone without going over the public internet.
Comment: Can span like that?
Comment: Sorry I think C is correct.
Comment: Nope. The answer is indeed C. You cannot span like that. Check the link below: "Each subnet must reside entirely within one Availability Zone and cannot span zones." https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html
Comment: Thanks, Leoattf for the link you shared.
Comment: it's C
Comment: Keyword here is a minimum throughput of 6 GBps. Only the FSx for Lustre with SSD option gives the sub-milli response and throughput of 6 GBps or more. B. Create an Amazon S3 bucket to store the raw data. Create an Amazon FSx for Lustre file system that uses persistent SSD storage. Select the option to import data from and export data to Amazon S3. Mount the file system on the EC2 instances. Refrences: https://aws.amazon.com/fsx/when-to-choose-fsx/
Comment: Create an Amazon S3 bucket to store the raw data Create an Amazon FSx for Lustre file system that uses persistent SSD storage Select the option to import data from and export data to Amazon S3 Mount the file system on the EC2 instances. Amazon FSx for Lustre uses SSD storage for submillisecond latencies and up to 6 GBps throughput, and can import data from and export data to Amazon S3. Additionally, the option to select persistent SSD storage will ensure that the data is stored on the disk and not lost if the file system is stopped.
Comment: Answer is B : FSx for Lustre with SSD option gives the sub-milli response and throughput of 6 GBps or more
Comment: I dont even think that NetApp comes for Linux
Comment: Amazon FSx for Lustre for compute-intensive workloads. - allows file-based applications to access data with hundreds of gigabytes per second of data, millions of IOPS, and sub millisecond latencies. - supports file access to thousands of EC2 instances and well SSD always wins ;)
Comment: sub-millisecondes == Lustre HDD vs SSD == for performance use SSD
Comment: Amazon FSx for Lustre with SSD: Amazon FSx for Lustre is designed for high-performance, parallel file processing workloads. Choosing SSD storage ensures fast I/O and meets the sub-millisecond latency requirement.
Comment: Voto por la B
Comment: So many of these are wrong, its good we have people that vote so we can get to the right answer!!
Comment: • Amazon FSx for Lustre with SSD storage can provide up to 260 GB/s of aggregate throughput and sub-millisecond latencies needed for this workload. • Persistent SSD storage ensures data durability in the file system. Data is also exported to S3 for backup storage. • The file system will import the initial 8 TB of raw data from S3, providing a fast storage tier for processing while retaining the data in S3. • The file system is mounted to the EC2 compute instances to distribute processing. • FSx for Lustre is optimized for high-performance computing workloads running on Linux, matching the EC2 environment.
Comment: Option A - FSx for NetApp ONTAP with ALL tiering policy would not provide fast enough storage tier for sub-millisecond latency. HDD tiers have higher latency. Option C - FSx for Lustre with HDD storage would not provide the throughput, IOPS or low latency needed. Option D - FSx for NetApp ONTAP with NONE tiering policy would require much more expensive SSD storage to meet requirements, increasing cost.
Comment: I vote B
Comment: FSX Lusture is 1000mbs per TB provisioned and we have 8TBs so gives us 8GBs . The netapp FSX appears a hard limit of 4gbs . https://aws.amazon.com/fsx/lustre/faqs/?nc=sn&loc=5 https://aws.amazon.com/fsx/netapp-ontap/faqs/
Comment: B is the best choice as it utilizes Amazon S3 for data storage, which is cost-effective and durable, and Amazon FSx for Lustre for high-performance file storage, which provides the required sub-millisecond latencies and minimum throughput of 6 GBps. Additionally, the option to import and export data to and from Amazon S3 makes it easier to manage and move data between the two services. B is the best option as it meets the performance requirements for sub-millisecond latencies and a minimum throughput of 6 GBps.
Comment: Amazon FSx for Lustre provides fully managed shared storage with the scalability and performance of the popular Lustre file system. It can deliver sub-millisecond latencies and hundreds of gigabytes per second of throughput.
Comment: Amazon EC2 Reserved Instances allow for significant cost savings compared to On-Demand instances for long-running, steady-state workloads like this one. Reserved Instances provide a capacity reservation, so the instances are guaranteed to be available for the duration of the reservation period. Amazon Aurora is a highly scalable, cloud-native relational database service that is designed to be compatible with MySQL and PostgreSQL. It can automatically scale up to meet growing storage requirements, so it can accommodate the application's database storage needs over time. By using Reserved Instances for Aurora, the cost savings will be significant over the long term.
Comment: Option B based on the fact that the DB storage will continue to grow, so on-demand will be a more suitable solution
Comment: Database STORAGE will grow, not performance need (and required instance size).
Comment: Since the application's database storage is continuously growing over time, it may be difficult to estimate the appropriate size of the Aurora cluster in advance, which is required when reserving Aurora. In this case, it may be more cost-effective to use Amazon RDS On-Demand Instances for the data storage layer. With RDS On-Demand Instances, you pay only for the capacity you use and you can easily scale up or down the storage as needed.
Comment: The Answer is C. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.html
Comment: Answer is C. From Aurora Reserved Instances documentation: If you have a DB instance, and you need to scale it to larger capacity, your reserved DB instance is automatically applied to your scaled DB instance. That is, your reserved DB instances are automatically applied across all DB instance class sizes. Size-flexible reserved DB instances are available for DB instances with the same AWS Region and database engine.
Comment: cost-effectively - the answer is C. The application runs 24 hours a day, 7 days a week. The application's database storage continues to grow over time.
Comment: Answer is C: Amazon EC2 Reserved Instances and Amazon Aurora Reserved Instances = less expensive than RDS.
Comment: Amazon Aurora reserved instances is used for the work load on predictable, so answer should be B
Comment: I think it's B as database storage will grow
Comment: Application runs 24x7 which means database is also used 24x7. The storage will grow and RDS On-Demand does not have auto-grow storage. You have to configure a storage size for RDS which means it will eventually run out of space. RDS On-Demand just scales CPU, not storage. Aurora has no storage limitation and can scale storage according to need which is what is required here
Comment: 24/7 forbids spot instances , so A is excluded Cost efficience require reserved instances , so D is excluded Between RDS and Aurora, Aurora is less expensive thanks to the reserved instance, so B is finally excluded Answer is C
Comment: I hope it should be B considering Database growth
Comment: Reserved instance applies to the DB instance size (CPU, RAM etc.), not storage.
Comment: My research concludes that From pure price point of view Aurora Reserved might/ usually be slightly more expensive than On-demand RDS. But RDS has less Operation overhead. For the 24x7 nature, I would vote C. But for pure cost-effective, B is less costly.
Comment: This option involves migrating the application layer to Amazon EC2 Reserved Instances and migrating the data storage layer to Amazon Aurora Reserved Instances. Amazon EC2 Reserved Instances provide a significant discount (up to 75%) compared to On-Demand Instance pricing, making them a cost-effective choice for applications that have steady state or predictable usage. Similarly, Amazon Aurora Reserved Instances provide a significant discount (up to 69%) compared to On-Demand Instance pricing.
Comment: To meet the requirements of migrating a legacy application from an on-premises data center to the AWS Cloud in a cost-effective manner, the most suitable option would be: C. Migrate the application layer to Amazon EC2 Reserved Instances. Migrate the data storage layer to Amazon Aurora Reserved Instances. Explanation: Migrating the application layer to Amazon EC2 Reserved Instances allows you to reserve EC2 capacity in advance, providing cost savings compared to On-Demand Instances. This is especially beneficial if the application runs 24/7. Migrating the data storage layer to Amazon Aurora Reserved Instances provides cost optimization for the growing database storage needs. Amazon Aurora is a fully managed relational database service that offers high performance, scalability, and cost efficiency.
Comment: nnascncnscnknkckl
Comment: Answer is C
Comment: Answer is C. Refer https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html => Size-flexible reserved DB instances
Comment: C: With Aurora Serverless v2, each writer and reader has its own current capacity value, measured in ACUs. Aurora Serverless v2 scales a writer or reader up to a higher capacity when its current capacity is too low to handle the load. It scales the writer or reader down to a lower capacity when its current capacity is higher than needed. This is sufficient to accommodate the growing data changes. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html#aurora-serverless-v2.how-it-works.scaling
Comment: Typically Amazon RDS cost less than Aurora. But here, it's Aurora reserved.
Comment: although agree and AWS wants you to choose Answer C. You can't convince a cloud accounting analyst that Aurora is cheaper than RDS. no matter what
Comment: Answer C https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html Discounts for reserved DB instances are tied to instance type and AWS Region.
Comment: AWS DataSync is a data transfer service that can copy large amounts of data between on-premises storage and Amazon FSx for Windows File Server at high speeds. It allows you to control the amount of bandwidth used during data transfer. • DataSync uses agents at the source and destination to automatically copy files and file metadata over the network. This optimizes the data transfer and minimizes the impact on your network bandwidth. • DataSync allows you to schedule data transfers and configure transfer rates to suit your needs. You can transfer 30 TB within 5 days while controlling bandwidth usage. • DataSync can resume interrupted transfers and validate data to ensure integrity. It provides detailed monitoring and reporting on the progress and performance of data transfers.
Comment: Option A - AWS Snowcone is more suitable for physically transporting data when network bandwidth is limited. It would not complete the transfer within 5 days. Option B - Amazon FSx File Gateway only provides access to files stored in Amazon FSx and does not perform the actual data migration from on-premises to FSx. Option D - AWS Transfer Family is for transferring files over FTP, FTPS and SFTP. It may require scripting to transfer 30 TB and monitor progress, and lacks bandwidth controls.
Comment: As read a little bit, I assume that B (FSx File Gateway) requires a little bit more configuration rather than C (DataSync). From Stephane Maarek course explanation about DataSync: An online data transfer service that simplifies, automates, and accelerates copying large amounts of data between on-premises storage systems and AWS Storage services, as well as between AWS Storage services. You can use AWS DataSync to migrate data located on-premises, at the edge, or in other clouds to Amazon S3, Amazon EFS, Amazon FSx for Windows File Server, Amazon FSx for Lustre, Amazon FSx for OpenZFS, and Amazon FSx for NetApp ONTAP.
Comment: Even if we allocate 60% of total bandwidth for the transfer, that would take 5d2h. Considering that " many other departments in the university share", that wouldn't be feasible. Ref. https://expedient.com/knowledgebase/tools-and-calculators/file-transfer-time-calculator/ On the other hand, snowcone isn't also a great option, because "you will receive the Snowcone device in approximately 4-6 days". Ref. https://aws.amazon.com/snowcone/faqs/#:~:text=You%20will%20receive%20the%20Snowcone,console%20for%20each%20Snowcone%20device.
Comment: Very unreasonable scenario. The least "bad" option is C, but that will definitely affect users in real production environments.
Comment: Snow cone can support up to 8TB for HDD and 15TB for each SSD devices. Shipped within 4-6 days. Data migration can begin on next 5 days. Does not use any amount of bandwidth and impact the production network. Device came with 1G and 10G Base-T Ethernet port. That's the Maximum performance in data transfer. defined in the question.
Comment: Bandwidth control = Data Sync https://docs.aws.amazon.com/datasync/latest/userguide/configure-bandwidth.html
Comment: Bandwidth Optimization and Control Transferring hot or cold data should not impede your business. DataSync is equipped with granular controls to optimize bandwidth consumptions. Throttle transfer speeds up to 10 Gbps during off hours and set limits when network availability is needed elsewhere
Comment: C. AWS DataSync
Comment: https://aws.amazon.com/datasync/features/
Comment: Bandwidth Optimization and Control Transferring hot or cold data should not impede your business. DataSync is equipped with granular controls to optimize bandwidth consumptions. Throttle transfer speeds up to 10 Gbps during off hours and set limits when network availability is needed elsewhere.
Comment: "Amazon FSx File Gateway" is for storing data, not for migrating. So the answer should be C.
Comment: Thanks for the explanation
Comment: Snowcone to small and delivertime to long. With DataSync you can set bandwidth limits - so this is fine solution.
Comment: Why not B?
Comment: Transfering will be much longerm rather then 5 days as required.
Comment: A not possible because Snowcone it's just 8TB and it takes 4-6 business days to deliver B why cannot be https://aws.amazon.com/storagegateway/file/fsx/? C I don't really get this D cannot be because not compatible - https://aws.amazon.com/aws-transfer-family/
Comment: With B you cannot "control the amount of bandwidth that the service uses", while C does exactly what is required here.
Comment: Voting C
Comment: C. - DataSync is Correct. A. Snowcone is incorrect. The question says data migration must take place within the next 5 days.AWS says: If you order, you will receive the Snowcone device in approximately 4-6 days.
Comment: DataSync can be used to migrate data between on-premises Windows file servers and Amazon FSx for Windows File Server with its compatibility for Windows file systems. The laboratory needs to migrate a large amount of data (30 TB) within a relatively short timeframe (5 days) and limit the impact on other departments' network traffic. Therefore, AWS DataSync can meet these requirements by providing fast and efficient data transfer with network throttling capability to control bandwidth usage.
Comment: https://docs.aws.amazon.com/datasync/latest/userguide/configure-bandwidth.html
Comment: https://aws.amazon.com/datasync/
Comment: For Minimum operational overhead, the 2 options A,C should be correct. A. Deploy Amazon CloudFront for content delivery and caching. C. Use Amazon Elastic Transcoder to convert the video files to more appropriate formats.
Comment: F - Fire the guy who created the current design
Comment: No, make him watch all those videos with buffering!
Comment: A & C. Admin has almost every answer wrong
Comment: A&C is correct
Comment: A and C
Comment: For Minimum operational overhead, the 2 options A,C should be correct. A. Deploy Amazon CloudFront for content delivery and caching. C. Use Amazon Elastic Transcoder to convert the video files to more appropriate formats.
Comment: For Minimum operational overhead, the 2 options A,C should be correct. A. Deploy Amazon CloudFront for content delivery and caching. C. Use Amazon Elastic Transcoder to convert the video files to more appropriate formats.
Comment: examtopics team, please fix this question, please allow to select two answer
Comment: Elastic Transcoder has been deprecated, and AWS encourage to use AWS Elemental MediaConvert right now: https://aws.amazon.com/blogs/media/how-to-migrate-workflows-from-amazon-elastic-transcoder-to-aws-elemental-mediaconvert/
Comment: AC is the correct answer
Comment: AC, the only possible answers.
Comment: It says choose two so I chose AC
Comment: A & C are the right answers.
Comment: Correct answer: AC
Comment: A and C. Transcoder does exactly what this needs.
Comment: A and C. CloudFront hs caching for A
Comment: a and c
Comment: Both A and C - I was not able to choose both https://aws.amazon.com/elastictranscoder/
Comment: Answer is D - Auto-scaling with target tracking
Comment: https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html
Comment: https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html
Comment: This is running on Fargate, so EC2 scaling (A and C) is out. Lambda (B) is too complex.
Comment: Target tracking will scale in/out the ECS cluster to maintain the average CPU utilization to a set value. e.g. <<<50%>>> Scale out when average CPU utilization is above 50% until average CPU utilization is back to 50%. And scale in when average CPU utilization is below 50% until average CPU utilization is back to 50%.
Comment: Answer is D
Comment: Answer is D - Auto-scaling with target tracking
Comment: Answer is D - Application Auto Scaling is a web service for developers and system administrators who need a solution for automatically scaling their scalable resources for individual AWS services beyond Amazon EC2.
Comment: should be D
Comment: https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html
Comment: Answer is D
Comment: D : auto-scaling with target tracking
Comment: AWS DataSync is a fully managed data transfer service that simplifies moving large amounts of data between on-premises storage systems and AWS services. It can also transfer data between different AWS services, including different AWS Regions. DataSync provides a simple, scalable, and automated solution to transfer data, and it minimizes the operational overhead because it is fully managed by AWS.
Comment: AWS DataSync is a fully managed data transfer service that simplifies moving large amounts of data between on-premises storage systems and AWS services. It can also transfer data between different AWS services, including different AWS Regions. DataSync provides a simple, scalable, and automated solution to transfer data, and it minimizes the operational overhead because it is fully managed by AWS.
Comment: Use AWS DataSync
Comment: Use AWS DataSync.
Comment: • AWS DataSync is a data transfer service optimized for moving large amounts of data between NFS file systems. It can automatically copy files and metadata between your NFS file systems in different AWS Regions. • DataSync requires minimal setup and management. You deploy a source and destination agent, provide the source and destination locations, and DataSync handles the actual data transfer efficiently in the background. • DataSync can schedule and monitor data transfers to keep source and destination in sync with minimal overhead. It resumes interrupted transfers and validates data integrity. • DataSync optimizes data transfer performance across AWS's network infrastructure. It can achieve high throughput with minimal impact to your operations.
Comment: Option B - AWS Snowball requires physical devices to transfer data. This incurs overhead to transport devices and manually load/unload data. It is not an online data transfer solution. Option C - Setting up and managing an SFTP server would require provisioning EC2 instances, handling security groups, and writing scripts to automate the data transfer - all of which demand more overhead than DataSync. Option D - AWS Database Migration Service is designed for migrating databases, not general file system data. It would require converting your NFS data into a database format, incurring additional overhead.
Comment: A only
Comment: Aaaaaa
Comment: A should be correct
Comment: Answer is C - SMB = storage gateway or FSx
Comment: C L: Amazon FSx for Windows File Server file system
Comment: SMB -> FSx
Comment: SMB = FSx for Windows File Server
Comment: Answer is C - SMB = storage gateway or FSx
Comment: • Amazon FSx for Windows File Server provides a fully managed native Windows file system that can be accessed using the industry-standard SMB protocol. This allows Windows clients like the gaming application to directly access file data. • FSx for Windows File Server handles time-consuming file system administration tasks like provisioning, setup, maintenance, file share management, backups, security, and software patching - reducing operational overhead. • FSx for Windows File Server supports high file system throughput, IOPS, and consistent low latencies required for performance-sensitive workloads. This makes it suitable for a gaming application. • The file system can be directly attached to EC2 instances, providing a performant shared storage solution for the gaming servers.
Comment: Option A - DataSync is for data transfer, not providing a shared file system. It cannot be mounted or directly accessed. Option B - A self-managed EC2 file share would require manually installing, configuring and maintaining a Windows file system and share. This demands significant overhead to operate. Option D - Amazon S3 is object storage, not a native file system. The data in S3 would need to be converted/formatted to provide file share access, adding complexity. S3 cannot be directly mounted or provide the performance of FSx.
Comment: Amazon FSx for Windows File Server
Comment: I vote C since FSx supports SMB
Comment: AWS FSx for Windows File Server is a fully managed native Microsoft Windows file system that is accessible through the SMB protocol. It provides features such as file system backups, integrated with Amazon S3, and Active Directory integration for user authentication and access control. This solution allows for the use of SMB clients to access the data and is fully managed, eliminating the need for the company to manage the underlying infrastructure.
Comment: C for me
Comment: Reasons: • Launching instances within a single AZ and using a cluster placement group provides the lowest network latency and highest bandwidth between instances. This maximizes performance for an in-memory database and high-throughput application. • Communications between instances in the same AZ and placement group are free, minimizing data transfer charges. Inter-AZ and public IP traffic can incur charges. • A cluster placement group enables the instances to be placed close together within the AZ, allowing the high network throughput required. Partition groups span AZs, reducing bandwidth. • Auto Scaling across zones could launch instances in AZs that increase data transfer charges. It may reduce network throughput, impacting performance.
Comment: In contrast: Option B - A partition placement group spans AZs, reducing network bandwidth between instances and potentially increasing costs. Option C - Auto Scaling alone does not guarantee the network throughput and cost controls required for this use case. Launching across AZs could increase data transfer charges. Option D - Step scaling policies determine how many instances to launch based on metrics alone. They lack control over network connectivity and costs between instances after launch.
Comment: Apart from the fact that BCD distribute the instances across AZ which is bad for inter-node network latency, I think the following article is really useful in understanding A: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: • Launching instances within a single AZ and using a cluster placement group provides the lowest network latency and highest bandwidth between instances. This maximizes performance for an in-memory database and high-throughput application. • Communications between instances in the same AZ and placement group are free, minimizing data transfer charges. Inter-AZ and public IP traffic can incur charges. • A cluster placement group enables the instances to be placed close together within the AZ, allowing the high network throughput required. Partition groups span AZs, reducing bandwidth.
Comment: Cluster placement group packs instances close together inside an Availability Zone. This strategy enables workloads to achieve the low-latency network performance.
Comment: Launch all EC2 instances in the same Availability Zone within the same AWS Region. Specify a placement group with cluster strategy when launching EC2 instances
Comment: Cluster - have low latency if its in same AZ and same region so Answer is "A"
Comment: Answer would be A - As part of selecting all the EC2 instances in the same availability zone, they all will be within the same DC and logically the latency will be very less as compared to the other Availability Zones.. As all the autoscaling nodes will also be on the same availability zones, (as per Placement groups with Cluster mode), this would provide the low-latency network performance Reference is below: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: A - Low latency, high net throughput
Comment: A placement group is a logical grouping of instances within a single Availability Zone, and it provides low-latency network connectivity between instances. By launching all EC2 instances in the same Availability Zone and specifying a placement group with cluster strategy, the application can take advantage of the high network throughput and low latency network connectivity that placement groups provide.
Comment: Cluster placement groups improves throughput between the instances which means less EC2 instances would be needed thus reducing costs.
Comment: A because Specify a placement group
Comment: It is option A: To achieve low latency, high throughput, and cost-effectiveness, the optimal solution is to launch EC2 instances as a placement group with the cluster strategy within the same Availability Zone.
Comment: Why not C?
Comment: You're thinking operational efficiency. The question asks for cost reduction.
Comment: Answer is A - Clustering
Comment: A : Cluster placement group
Comment: AWS Storage Gateway Volume Gateway provides two configurations for connecting to iSCSI storage, namely, stored volumes and cached volumes. The stored volume configuration stores the entire data set on-premises and asynchronously backs up the data to AWS. The cached volume configuration stores recently accessed data on-premises, and the remaining data is stored in Amazon S3. Since the company wants only its recently accessed data to remain stored locally, the cached volume configuration would be the most appropriate. It allows the company to keep frequently accessed data on-premises and reduce the need for scaling its iSCSI storage while still providing access to all data through the AWS cloud. This configuration also provides low-latency access to frequently accessed data and cost-effective off-site backups for less frequently accessed data.
Comment: You're correct but a small mistake that the stored volume configuration stores the entire data set on-premises and asynchronously backs up the data to AWS (S3). The cached volume is low latency access to most recent data.
Comment: https://docs.amazonaws.cn/en_us/storagegateway/latest/vgw/StorageGatewayConcepts.html#storage-gateway-cached-concepts
Comment: Frequently accessed data = AWS Storage Gateway Volume Gateway cached volumes
Comment: The best AWS solution to meet the requirements is to use AWS Storage Gateway cached volumes (option D). The key points: Company migrating on-prem app servers to AWS Want to minimize scaling on-prem iSCSI storage Only recent data should remain on-premises The AWS Storage Gateway cached volumes allow the company to connect their on-premises iSCSI storage to AWS cloud storage. It stores frequently accessed data locally in the cache for low-latency access, while older data is stored in AWS.
Comment: • Volume Gateway cached volumes store entire datasets on S3, while keeping a portion of recently accessed data on your local storage as a cache. This meets the goal of minimizing on-premises storage needs while keeping hot data local. • The cache provides low-latency access to your frequently accessed data, while long-term retention of the entire dataset is provided durable and cost-effective in S3. • You get virtually unlimited storage on S3 for your infrequently accessed data, while controlling the amount of local storage used for cache. This simplifies on-premises storage scaling. • Volume Gateway cached volumes support iSCSI connections from on-premises application servers, allowing a seamless migration experience. Servers access local cache and S3 storage volumes as iSCSI LUNs.
Comment: In contrast: Option A - S3 File Gateway only provides file interfaces (NFS/SMB) to data in S3. It does not support block storage or cache recently accessed data locally. Option B - Tape Gateway is designed for long-term backup and archiving to virtual tape cartridges on S3. It does not provide primary storage volumes or local cache for low-latency access. Option C - Volume Gateway stored volumes keep entire datasets locally, then asynchronously back them up to S3. This does not meet the goal of minimizing on-premises storage needs.
Comment: I vote D
Comment: Agree with D
Comment: recently accessed data to remain stored locally - cached
Comment: D. AWS Storage Gateway Volume Gateway cached volumes
Comment: recently accessed data to remain stored locally - cached
Comment: B & D https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/
Comment: The answer is either BC or BD, depending on how you interpret "The company runs several active... instances for 90 days for 90 days." D: it assumes the instances will only run for 90 days, so reserved instances can't be the answer, since it requires 1-3 years utilization. C: it assumes there is no idle instances since they've been active for the last 90 days.
Comment: B: Use the Trusted Advisor recommendations from the consolidated billing account to see all RDS instance checks at the same time. This option allows the finance team to see all RDS instance checks across all AWS accounts in one place. Since the company uses consolidated billing, this account will have access to all of the AWS accounts' Trusted Advisor recommendations. C: Review the Trusted Advisor check for Amazon RDS Reserved Instance Optimization. This check can help identify cost savings opportunities for RDS by identifying instances that can be covered by Reserved Instances. This can result in significant savings on RDS costs.
Comment: BD is the answer-Amazon Redshift Reserved Node Optimization and Relational Database Service (RDS) Reserved Instance Optimization check are not available to accounts linked in consolidated billing.
Comment: "you can reserve a DB instance for a one- or three-year term". We only have data for 90 days. I feel it too risky to commit for 1/3 year(s) without information on future usage. If we knew that we expected the same usage pattern for the next 1,2,3 years, Id agree with C.
Comment: B) Use the Trusted Advisor recommendations from the consolidated billing account to see all RDS instance checks at the same time. This option allows the finance team to see all RDS instance checks across all AWS accounts in one place. Since the company uses consolidated billing, this account will have access to all of the AWS accounts' Trusted Advisor recommendations. C) Review the Trusted Advisor check for Amazon RDS Reserved Instance Optimization. This check can help identify cost savings opportunities for RDS by identifying instances that can be covered by Reserved Instances. This can result in significant savings on RDS costs.
Comment: Reserved Instances are for 1 or 3 years. Not for 90 days
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/
Comment: Insights: The company runs several active high performance Amazon RDS for Oracle On-Demand DB instances for 90 days So it's clear that this company need to check the configuration of any Amazon Relational Database Service (Amazon RDS) for any database (DB) instances that appear to be idle.
Comment: B&C AWS Trusted Advisor is an online resource to help you reduce cost, increase performance, and improve security by optimizing your AWS environment. (...) Recommendations are based on the previous calendar month's hour-by-hour usage aggregated across all consolidated billing accounts. https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/aws-trusted-advisor.html Amazon EC2 Reserved Instance Optimization: An important part of using AWS involves balancing your Reserved Instance (RI) purchase against your On-Demand Instance usage. This check provides recommendations on which RIs will help reduce the costs incurred from using On-Demand Instances. We create these recommendations by analyzing your On-Demand usage for the past 30 days. We then categorizing the usage into eligible categories for reservations. https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html#amazon-ec2-reserved-instances-optimization
Comment: If you're choosing D for the idle instances, Amazon RDS Reserved Instance Optimization Trusted Advisor check includes recommendations related to underutilized and idle RDS instances. It helps identify instances that are not fully utilized and provides recommendations on how to optimize costs, such as resizing or terminating unused instances, or purchasing reserved instances to match usage patterns more efficiently.
Comment: Reserved Instances can be shared across accounts, and that is the reason why we need to check the consolidated bill.
Comment: BC we don't want to check Idle instances because the instances were active for last 90 days. Idle means it was inactive for at least 7 days.
Comment: BD we don't want to check Idle instances because the instances were active for last 90 days. Idle means it was inactive for at least 7 days.
Comment: Then why you voted for D?
Comment: Reserved Instance Optimization "checks your usage of RDS and provides recommendations on purchase of Reserved Instances to help reduce costs incurred from using RDS On-Demand." In other words, it is not about optimizing reserved instances (as many here think), it about optimizing on-demand instances by converting them to reserved ones. "Idle DB Instances" check is about databases that have "not had a connection for a prolonged period of time", which we know is not the case here.
Comment: why no one considers AD. C is not the option since reserved instance is considered in case of long-term usage while it is 90 days here. But B is using consolidated billing which covers the high level billing overview of cost but not that specific for RDS running instance. should we only need to use Trust advisor for accounts where RDS is running?
Comment: The question mentions that the instances are active, so it cannot be D as it checks for idle instances
Comment: Can someone explain why so many people say it's D and not C? It's very clear that 90 days means reserved instances.
Comment: Sorry I canged the Answer C to D ， Because Reserved Instances don't last for 90 days
Comment: But you're wrong, C is about optimizing on-demand instances (that we have here) by converting them to reserved instances (which is what we want).
Comment: S3 Storage Lens is a fully managed S3 storage analytics solution that provides a comprehensive view of object storage usage, activity trends, and recommendations to optimize costs. Storage Lens allows you to analyze object access patterns across all of your S3 buckets and generate detailed metrics and reports.
Comment: S3 Storage Lens includes an interactive dashboard which you can find in the S3 console. The dashboard gives you the ability to perform filtering and drill-down into your metrics to really understand how your storage is being used. The metrics are organized into categories like data protection and cost efficiency, to allow you to easily find relevant metrics.
Comment: Anyone passed the exam can confirm the right answer ? A or D
Comment: A S3 Storage Lens is the first cloud storage analytics solution to provide a single view of object storage usage and activity across hundreds, or even thousands, of accounts in an organization, with drill-downs to generate insights at multiple aggregation levels.
Comment: On the other hand, Option B suggests using the S3 dashboard in the AWS Management Console, which provides a straightforward and user-friendly interface to monitor S3 bucket access patterns. This option may have less operational overhead compared to setting up and managing Storage Lens. Additionally, for simply identifying rarely accessed buckets, the built-in metrics and access analysis provided by the S3 dashboard can often suffice without the need for advanced analytics offered by Storage Lens. Therefore, Option B is considered to have less operational overhead for the specific task described in the question.
Comment: But nowhere on S3 Storage Lens dashboard this information is available; that when the bucket is accessed last time. But it gives insight on the bucket's size. with this information we can check if files can be moved to less costly storage class. This way we can reduce storage cost..... The information which is the main requirement of the given scenario, is available when we use Cloudtrail logs ... so i choose option D.
Comment: if the bucket is being accessed frequently then we can leave it as it is, otherwise we can move the files to infrequent access storage class thus can save some money.
Comment: S3 Storage Lens is a fully managed S3 storage analytics solution that provides a comprehensive view of object storage usage, activity trends, and recommendations to optimize costs. Storage Lens allows you to analyze object access patterns across all of your S3 buckets and generate detailed metrics and reports.
Comment: Amazon S3 Storage Lens was designed to handle this requirement.
Comment: A missed turning on monitoring. It can also help you learn about your customer base and understand your Amazon S3 bill. By default, Amazon S3 doesn't collect server access logs. When you enable logging, Amazon S3 delivers access logs for a source bucket to a target bucket that you choose. I could not find that S3 storage Lens examples online showing using Lens to identify idle S3 buckets. Instead I find using S3 Access Logging. Hmm.
Comment: How will you find when a bucket was used the last time if you turn on logging NOW?
Comment: S3 Storage Lens is a cloud-storage analytics feature that provides you with 29+ usage and activity metrics, including object count, size, age, and access patterns. This data can help you understand how your data is being used and identify areas where you can optimize your storage costs. The S3 Storage Lens dashboard provides an interactive view of your storage usage and activity trends. This makes it easy to identify buckets that are no longer being accessed or are rarely accessed. The S3 Storage Lens dashboard is a fully managed service, so there is no need to set up or manage any additional infrastructure.
Comment: "S3 Storage Lens" seems to be the popular answer, however, where in Storage Lens can you see if a bucket/object is being USED? I see all kinds of stats, but not that.
Comment: "S3 Storage Lens delivers organization-wide visibility into object storage usage, activity trends, and makes actionable recommendations to optimize costs..."
Comment: https://aws.amazon.com/blogs/aws/s3-storage-lens/
Comment: The S3 Storage Lens dashboard provides visibility into storage metrics and activity patterns to help optimize storage costs. It shows metrics like objects added, objects deleted, storage consumed, and requests. It can filter by bucket, prefix, and tag to analyze specific subsets of data
Comment: B) The standard S3 console dashboard provides basic info but would require manually analyzing metrics for each bucket. This does not scale well and requires significant overhead. C) Turning on the BucketSizeBytes metric and analyzing the data in Athena may provide insights but would require enabling metrics, building Athena queries, and analyzing the results. This requires more operational effort than option A. D) Enabling CloudTrail logging and monitoring the logs in CloudWatch Logs could provide access pattern data but would require setting up CloudTrail, monitoring the logs, and analyzing the relevant info. This option has the highest operational overhead
Comment: https://aws.amazon.com/blogs/aws/s3-storage-lens/
Comment: S3 Storage Lens provides a dashboard with advanced activity metrics that enable the identification of infrequently accessed and unused buckets. This can help a solutions architect optimize storage costs without incurring additional operational overhead.
Comment: it looks like it's A
Comment: To reduce the cost associated with data transfers and maintain or improve performance, a solutions architect should use Amazon CloudFront, a content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. Deploying a CloudFront distribution with the existing S3 bucket as the origin will allow the company to serve the data to customers from edge locations that are closer to them, reducing data transfer costs and improving performance. Directing customer requests to the CloudFront URL and switching to CloudFront signed URLs for access control will enable customers to access the data securely and efficiently.
Comment: A: Speeds uploads C: Increases the cost rather than reducing it D: Stopped reading after "Modify the web application..."
Comment: To reduce the cost associated with data transfers and maintain or improve performance, a solutions architect should use Amazon CloudFront, a content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds.
Comment: Technically both option B and C will work. But because cost is a factor then Amazon CloudFront should be the preferred option.
Comment: B. 1. Amazon CloudFront caches content at edge locations -- reducing the need for frequent data transfer from S3 bucket -- thus significantly lowering data transfer costs (as compared to directly serving data from S3 bucket to customers in different regions) 2. CloudFront delivers content to users from the nearest edge location -- minimizing latency -- improves performance for customers A - focus on accelerating uploads to S3 which may not necessarily improve the performance needed for serving datasets to customers C - helps with redundancy and data availability but does not necessarily offer cost savings for data transfer. D - complex to implement, does not address data transfer cost
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
Comment: B. Deploy an Amazon CloudFront distribution with the existing S3 bucket as the origin. Direct customer requests to the CloudFront URL. Switch to CloudFront signed URLs for access control. https://www.examtopics.com/discussions/amazon/view/68990-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Quote types need to be separated: SNS message filtering can be used to publish messages to the appropriate SQS queue based on the quote type, ensuring that quotes are separated by type. Quotes must be responded to within 24 hours and must not get lost: SQS provides reliable and scalable queuing for messages, ensuring that quotes will not get lost and can be processed in a timely manner. Additionally, each backend application server can use its own SQS queue, ensuring that quotes are processed efficiently without any delay. Operational efficiency and minimizing maintenance: Using a single SNS topic and multiple SQS queues is a scalable and cost-effective approach, which can help to maximize operational efficiency and minimize maintenance. Additionally, SNS and SQS are fully managed services, which means that the company will not need to worry about maintenance tasks such as software updates, hardware upgrades, or scaling the infrastructure.
Comment: C is the best option
Comment: SQS + SNS = fanout
Comment: Option C would be the most suitable solution to meet the requirements while maximizing operational efficiency and minimizing maintenance. Explanation: Amazon SNS (Simple Notification Service) allows for the creation of a single topic to which multiple subscribers can be attached. In this scenario, each quote type can be considered a subscriber. Amazon SQS (Simple Queue Service) queues can be subscribed to the SNS topic, and SNS message filtering can be used to direct messages to the appropriate SQS queue based on the quote type. This setup ensures that quotes are separated by quote type and that they are not lost. Each backend application server can then poll its own SQS queue to retrieve and process messages. This architecture is efficient, scalable, and requires minimal maintenance, as it leverages managed AWS services without the need for complex custom code or infrastructure setup.
Comment: I originally went for D due to searching requirements but Open Search is for analytics and logs and nothing to do with data coming from streams as in this question.
Comment: Quote types need to be separated: SNS message filtering can be used to publish messages to the appropriate SQS queue based on the quote type, ensuring that quotes are separated by type. Quotes must be responded to within 24 hours and must not get lost: SQS provides reliable and scalable queuing for messages, ensuring that quotes will not get lost and can be processed in a timely manner. Additionally, each backend application server can use its own SQS queue, ensuring that quotes are processed efficiently without any delay. Operational efficiency and minimizing maintenance: Using a single SNS topic and multiple SQS queues is a scalable and cost-effective approach, which can help to maximize operational efficiency and minimize maintenance. Additionally, SNS and SQS are fully managed services, which means that the company will not need to worry about maintenance tasks such as software updates, hardware upgrades, or scaling the
Comment: Keyword is "..and must not get lost" = SQS
Comment: Create a single SNS topic Subscribe separate SQS queues per quote type Use SNS message filtering to send messages to proper queue Backend servers poll their respective SQS queue The key points: Quote requests must be processed within 24 hrs without loss Need to maximize efficiency and minimize maintenance Requests separated by quote type
Comment: This wrong answers from examtopic are getting me so frustrated. Which one is the correct answer then?
Comment: This is the SNS fan-out technique where you will have one SNS service to many SQS services https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html
Comment: SNS Fan-out fans message to all subscribers, this uses SNS filtering to publish the message only to the right SQS queue (not all of them).
Comment: https://aws.amazon.com/getting-started/hands-on/filter-messages-published-to-topics/
Comment: Enough with CloudFront already.
Comment: Hahaha..cloudfront too hyped :)
Comment: This whole exam seems like a sales pitch for CloudFront and SQS... lol!
Comment: Amazon CloudFront is a content delivery network (CDN) that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. CloudFront supports signed URLs that provide authorized access to your content. This feature allows the company to control who can access their content and for how long, providing a secure and scalable solution for millions of users.
Comment: great explanation!
Comment: CF always for reaching places
Comment: Use Amazon CloudFront. Provide signed URLs to stream content.
Comment: Use Amazon CloudFront. Provide signed URLs to stream content.
Comment: C is correct.
Comment: Cloudfront is the correct solution.
Comment: Feel your pain :D hahaha
Comment: C https://www.amazonaws.cn/en/cloudfront/
Comment: "without selecting a particular instance type" = serverless
Comment: With Aurora Serverless for MySQL, you don't need to select a particular instance type, as the service automatically scales up or down based on the application's needs.
Comment: The DBA had one job and he doesn't want to do it... so B it is
Comment: without selecting a particular instance type = Amazon Aurora Serverless for MySQL
Comment: without selecting a particular instance type = Amazon Aurora Serverless for MySQL
Comment: B. Amazon Aurora Serverless for MySQL
Comment: What's the difference between A and B. I think Aurora is serverless, isn't it?
Comment: seems serverless is an option of amazon aurora. Not a very good naming scheme.
Comment: Bbbbbbb
Comment: https://aws.amazon.com/rds/aurora/serverless/
Comment: Amazon Aurora Serverless for MySQL is a fully managed, auto-scaling relational database service that scales up or down automatically based on the application demand. This service provides all the capabilities of Amazon Aurora, such as high availability, durability, and security, without requiring the customer to provision any database instances. With Amazon Aurora Serverless for MySQL, the sales team can enjoy minimal downtime since the database is designed to automatically scale to accommodate the increased traffic. Additionally, the service allows the customer to pay only for the capacity used, making it cost-effective for infrequent access patterns. Amazon RDS for MySQL could also be an option, but it requires the customer to select an instance type, and the database administrator would need to monitor and adjust the instance size manually to accommodate the increasing traffic.
Comment: Minimal downtime points directly to Aurora Serverless
Comment: AWS Shield for DDOS Amazon Macie for discover and protect sensitive date Amazon GuardDuty for intelligent thread discovery to protect AWS account Amazon Inspector for automated security assessment. like known Vulnerability
Comment: Whenever I feel vulnerable, I use AWS Inspector..
Comment: Amazon Inspector for automated security assessment. like known Vulnerability
Comment: AWS Shield for DDOS Amazon Macie for discover and protect sensitive date Amazon GuardDuty for intelligent thread discovery to protect AWS account Amazon Inspector for automated security assessment. like known Vulnerability
Comment: vulnerabilities = Amazon Inspector malicious activity = Amazon GuardDuty
Comment: Enable Amazon Inspector Deploy Inspector agents to EC2 instances Use Lambda to generate and distribute vulnerability reports The key points: Migrate on-prem apps with vulnerabilities to EC2 Need active scanning of EC2 instances for vulnerabilities Require reports on findings
Comment: Amazon Inspector: • Performs active vulnerability scans of EC2 instances. It looks for software vulnerabilities, unintended network accessibility, and other security issues. • Requires installing an agent on EC2 instances to perform scans. The agent must be deployed to each instance. • Provides scheduled scan reports detailing any findings of security risks or vulnerabilities. These reports can be used to patch or remediate issues. • Is best suited for proactively detecting security weaknesses and misconfigurations in your AWS environment.
Comment: Amazon GuardDuty: • Monitors for malicious activity like unusual API calls, unauthorized infrastructure deployments, or compromised EC2 instances. It uses machine learning and behavioral analysis of logs. • Does not require installing any agents. It relies on analyzing AWS CloudTrail, VPC Flow Logs, and DNS logs. • Alerts you to any detected threats, suspicious activity or policy violations in your AWS accounts. These alerts warrant investigation but may not always require remediation. • Is focused on detecting active threats, unauthorized behavior, and signs of a compromise in your AWS environment. • Can also detect some vulnerabilities and misconfigurations but coverage is not as broad as a dedicated service like Inspector.
Comment: Amazon Inspector is a vulnerability scanning tool that you can use to identify potential security issues within your EC2 instances. It is a kind of automated security assessment service that checks the network exposure of your EC2 or latest security state for applications running into your EC2 instance. It has ability to auto discover your AWS workload and continuously scan for the open loophole or vulnerability.
Comment: Amazon Inspector is a vulnerability scanning tool that you can use to identify potential security issues within your EC2 instances. Guard Duty continuously monitors your entire AWS account via Cloud Trail, Flow Logs, DNS Logs as Input.
Comment: :) C is the correct https://cloudkatha.com/amazon-guardduty-vs-inspector-which-one-should-you-use/
Comment: Please, read the link you sent: Amazon Inspector is a vulnerability scanning tool that you can use to identify potential security issues within your EC2 instances. GuardDuty is very critical part to identify threats, based on that findings you can setup automated preventive actions or remediation's. So Answer is D.
Comment: Document itself saying that Amazon Inspector is a vulnerability scanning tool hence correct Answer is D
Comment: https://cloudkatha.com/amazon-guardduty-vs-inspector-which-one-should-you-use/
Comment: Amazon Inspector is a security assessment service that helps to identify security vulnerabilities and compliance issues in applications deployed on Amazon EC2 instances. It can be used to assess the security of applications that are deployed on Amazon EC2 instances, including those that are custom-built. To use Amazon Inspector, the Amazon Inspector agent must be installed on the EC2 instances that need to be assessed. The agent collects data about the instances and sends it to Amazon Inspector for analysis. Amazon Inspector then generates a report that details any security vulnerabilities that were found and provides guidance on how to remediate them. By configuring an AWS Lambda function, the company can automate the generation and distribution of reports that detail the findings. This means that reports can be generated and distributed as soon as vulnerabilities are detected, allowing the company to take action quickly.
Comment: I'm a little confused on how someone came up with C, it is definitely D.
Comment: Amazon Inspector
Comment: Amazon Inspector is an automated vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure. https://aws.amazon.com/inspector/features/?nc=sn&loc=2
Comment: I think D
Comment: Inspector for EC2
Comment: Ddddddd
Comment: By migrating the script to AWS Lambda, the company can take advantage of the auto-scaling feature of the service. AWS Lambda will automatically scale resources to match the size of the workload. This means that the company will not have to worry about provisioning or managing instances as the number of messages increases, resulting in lower operational costs
Comment: The key points are: Currently using an EC2 instance to poll SQS and process messages Want to reduce costs while handling growing message volume By migrating the polling script to a Lambda function, the company can avoid the cost of running a dedicated EC2 instance. Lambda functions scale automatically to handle message spikes. And Lambda billing is based on actual usage, resulting in cost savings versus provisioned EC2 capacity.
Comment: reduce operational costs = serverless = Lambda functions
Comment: Lambda costs money only when it's processing, not when idle
Comment: Agree with C
Comment: the answer is C. With this option, you can reduce operational cost as the question mentioned
Comment: AWS Lambda is a serverless compute service that allows you to run your code without provisioning or managing servers. By migrating the script to an AWS Lambda function, you can eliminate the need to maintain an EC2 instance, reducing operational costs. Additionally, Lambda automatically scales to handle the increasing number of messages in the SQS queue.
Comment: It Should be C. Lambda allows you to execute code without provisioning or managing servers, so it is ideal for running scripts that poll for and process messages in an Amazon SQS queue. The scaling of the Lambda function is automatic, and you only pay for the actual time it takes to process the messages.
Comment: To reduce the operational overhead, it should be: D. Use AWS Systems Manager Run Command to run the script on demand.
Comment: No, replace EC2 instead by using lambda to reduce costs
Comment: So every time an item is added to the queue, you log into AWS Systems Manager through your browser, select "Run Command" and select your instance and enter the command to run the script?
Comment: very sarcastic question :)
Comment: Time to sell some Glue. I believe these kind of questions are there to indoctrinate us into acknowledging how blessed we are to have managed services like AWS Glue when you look at other horrible and painful options
Comment: A, AWS Glue is a fully managed ETL service that can extract data from various sources, transform it into the required format, and load it into a target data store. In this case, the ETL job can be configured to read the CSV files from Amazon S3, transform the data into a format that can be loaded into Amazon Redshift, and load it into an Amazon Redshift table. B requires the development of a custom script to convert the CSV files to SQL files, which could be time-consuming and introduce additional operational overhead. C, while using serverless technology, requires the additional use of DynamoDB to store the processed data, which may not be necessary if the data is only needed in Amazon Redshift. D, while an option, is not the most efficient solution as it requires the creation of an EMR cluster, which can be costly and complex to manage.
Comment: B - Developing a script is surely not minimizing operational effort C - Stores data in DynamoDB where the new app cannot use it D - Could work but is total overkill (EMR is for Big Data analysis, not for simple ETL)
Comment: A-ETL is serverless & best suited with the requirement who primary job is ETL B-Usage of Ec2 adds operational overhead & incur costs C-DynamoDB(NoSql) does suit the requirement as company is performing SQL queries D-EMR adds operational overhead & incur costs
Comment: A-ETL is serverless & best suited with the requirement who primary job is ETL B-Usage of Ec2 adds operational overhead & incur costs C-DynamoDB(NoSql) does suit the requirement as company is performing SQL queries D-EMR adds operational overhead & incur costs
Comment: Data transformation = AWS Glue
Comment: Create an AWS Glue ETL job to process the CSV files Configure the job to run on a schedule Output the transformed data to Amazon Redshift The key points: Legacy app generates CSV files in S3 New app requires data in Redshift or S3 Need to transform CSV to support new app with minimal ops overhead
Comment: Glue is server less and has less operational head than EMR so A.
Comment: o meet the requirement with the least operational overhead, a serverless approach should be used. Among the options provided, option C provides a serverless solution using AWS Lambda, S3, and DynamoDB. Therefore, the solution should be to create an AWS Lambda function and an Amazon DynamoDB table. Use an S3 event to invoke the Lambda function. Configure the Lambda function to perform an extract, transform, and load (ETL) job to process the .csv files and store the processed data in the DynamoDB table. Option A is also a valid solution, but it may involve more operational overhead than Option C. With Option A, you would need to set up and manage an AWS Glue job, which would require more setup time than creating an AWS Lambda function. Additionally, AWS Glue jobs have a minimum execution time of 10 minutes, which may not be necessary or desirable for this use case. However, if the data processing is particularly complex or requires a lot of data transformation, AWS Glue may be a more appropriate solution.
Comment: Important point: The COTS performs complex SQL queries to analyze data in Amazon Redshift. If you use DynamoDB -> No SQL querires. Option A makes more sense.
Comment: Creating and maintaining a Lambda function is more "operational overhead" than using a ready-made service such as Glue. But more important, answer C says "store the processed data in the DynamoDB table" while the application can "analyze data that is stored in Amazon Redshift and Amazon S3 only".
Comment: A would be the best solution as it involves the least operational overhead. With this solution, an AWS Glue ETL job is created to process the .csv files and store the processed data directly in Amazon Redshift. This is a serverless approach that does not require any infrastructure to be provisioned, configured, or maintained. AWS Glue provides a fully managed, pay-as-you-go ETL service that can be easily configured to process data from S3 and load it into Amazon Redshift. This approach allows the legacy application to continue to produce data in the CSV format that it currently uses, while providing the new COTS application with the ability to analyze the data using complex SQL queries.
Comment: A https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format-csv-home.html I AGREE AFTER READING LINK
Comment: A: https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html
Comment: A. Enable AWS CloudTrail and use it for auditing. CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs and APIs. By enabling CloudTrail, the company can track user activity and changes to AWS resources, and monitor compliance with internal policies and external regulations. D. Enable AWS Config and create rules for auditing and compliance purposes. AWS Config provides a detailed inventory of the AWS resources in your account, and continuously records changes to the configurations of those resources. By creating rules in AWS Config, the company can automate the evaluation of resource configurations against desired state, and receive alerts when configurations drift from compliance. Options B, C, and E are not directly relevant to the requirement of tracking and auditing inventory and configuration changes.
Comment: A. Enable AWS CloudTrail and use it for auditing. CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs and APIs. By enabling CloudTrail, the company can track user activity and changes to AWS resources, and monitor compliance with internal policies and external regulations. D. Enable AWS Config and create rules for auditing and compliance purposes. AWS Config provides a detailed inventory of the AWS resources in your account, and continuously records changes to the configurations of those resources. By creating rules in AWS Config, the company can automate the evaluation of resource configurations against desired state, and receive alerts when configurations drift from compliance. Options B, C, and E are not directly relevant to the requirement of tracking and auditing inventory and configuration changes.
Comment: A. Enable AWS CloudTrail and use it for auditing. CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs and APIs. By enabling CloudTrail, the company can track user activity and changes to AWS resources, and monitor compliance with internal policies and external regulations. D. Enable AWS Config and create rules for auditing and compliance purposes. AWS Config provides a detailed inventory of the AWS resources in your account, and continuously records changes to the configurations of those resources. By creating rules in AWS Config, the company can automate the evaluation of resource configurations against desired state, and receive alerts when configurations drift from compliance.
Comment: I am gonna go with CD AWS Cloudtrail is already enabled so no need to enable it and for the auding we are gonna use AWS config Answer D C because Trusted advisor checks the security groups
Comment: CloudTrail is not enabled by default or in the question scenario. Even if it was, Trusted Advisor would just give you recommendations and usage reports. It won't audit anything for you
Comment: "AWS CloudTrail is already enabled" says who?
Comment: A) Enable AWS CloudTrail and use it for auditing. AWS CloudTrail provides a record of API calls and can be used to audit changes made to EC2 instances and security groups. By analyzing CloudTrail logs, the solutions architect can track who provisioned oversized instances or modified security groups without proper approval. D) Enable AWS Config and create rules for auditing and compliance purposes. AWS Config can record the configuration changes made to resources like EC2 instances and security groups. The solutions architect can create AWS Config rules to monitor for non-compliant changes, like launching certain instance types or opening security group ports without permission. AWS Config would alert on any violations of these rules.
Comment: The other options would not fully meet the auditing and change tracking requirements: B) Data lifecycle policies control when EC2 instances are backed up or deleted but do not audit configuration changes. C) AWS Trusted Advisor security checks may detect some compliance violations after the fact but do not comprehensively log changes like AWS CloudTrail and AWS Config do. E) CloudFormation templates enable rollback but do not provide an audit trail of changes. The solutions architect would not know who made unauthorized modifications in the first place.
Comment: Yes A and D
Comment: AGREE WITH ANSWER - A & D CloudTrail and Config
Comment: CloudTrail and Config
Comment: Answer is A Using AWS Systems Manager Session Manager to connect to the EC2 instances is a secure option as it eliminates the need for inbound SSH ports and removes the requirement to manage SSH keys manually. It also provides a complete audit trail of user activity. This solution requires no additional software to be installed on the EC2 instances.
Comment: A - Systems Manager Session Manager has EXACTLY that purpose, 'providing secure access to EC2 instances' B - STS can generate temporary IAM credentials or access keys but NOT SSH keys C - Does not 'remove all shared keys' as requested D - Cognito is not meant for internal users, and whole setup is complex
Comment: B - Querying is just a feature of Redshift but primarily it's a Data Warehouse - the question says nothing that historical data would have to be stored or accessed or analyzed
Comment: The key reasons why: STS can generate short-lived credentials that provide temporary access to the EC2 instances for administering them. The credentials can be generated on-demand each time access is needed, eliminating the risks of using permanent shared SSH keys. No infrastructure like bastion hosts needs to be maintained. The on-premises administrators can use the familiar SSH tools with the temporary keys.
Comment: Session Manager provides secure and auditable node management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.
Comment: The key reasons why: STS can generate short-lived credentials that provide temporary access to the EC2 instances for administering them. The credentials can be generated on-demand each time access is needed, eliminating the risks of using permanent shared SSH keys. No infrastructure like bastion hosts needs to be maintained. The on-premises administrators can use the familiar SSH tools with the temporary keys.
Comment: STS provides temporary IAM credentials, not SSH keys
Comment: Using AWS Security Token Service (AWS STS) to generate one-time SSH keys on demand is a secure and efficient way to provide access to the EC2 instances without the need for shared SSH keys. STS is a fully managed service that can be used to generate temporary security credentials, allowing systems administrators to connect to the EC2 instances without having to share SSH keys. The temporary credentials can be generated on demand, reducing the administrative overhead associated with managing SSH access
Comment: Can you please provide documentation about generating a one-time SSH with STS?
Comment: AWS Systems Manager Session Manager provides secure shell access to EC2 instances without the need for SSH keys. It meets the security requirement to remove shared SSH keys while minimizing administrative overhead.
Comment: Session Manager is a fully managed AWS Systems Manager capability. With Session Manager, you can manage your Amazon Elastic Compute Cloud (Amazon EC2) instances, edge devices, on-premises servers, and virtual machines (VMs). You can use either an interactive one-click browser-based shell or the AWS Command Line Interface (AWS CLI). Session Manager provides secure and auditable node management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys. Session Manager also allows you to comply with corporate policies that require controlled access to managed nodes, strict security practices, and fully auditable logs with node access details, while providing end users with simple one-click cross-platform access to your managed nodes. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
Comment: Who should use Session Manager? Any AWS customer who wants to improve their security and audit posture, reduce operational overhead by centralizing access control on managed nodes, and reduce inbound node access. Information Security experts who want to monitor and track managed node access and activity, close down inbound ports on managed nodes, or allow connections to managed nodes that don't have a public IP address. Administrators who want to grant and revoke access from a single location, and who want to provide one solution to users for Linux, macOS, and Windows Server managed nodes. Users who want to connect to a managed node with just one click from the browser or AWS CLI without having to provide SSH keys.
Comment: If the systems administrators need to access the EC2 instances from an on-premises environment, using Session Manager may not be the ideal solution.
Comment: You guys seriously don't want to go to SMSM for Avery Single EC2. You have to create solution not used services for one time access. Bastion will give you option to manage 1000s EC2 machines from 1. Plus you can use Ansible from it.
Comment: Question:" the company's security team is mandating the removal of all shared keys", answer C can't be right because it says:"Allow shared SSH access to a set of bastion instances".
Comment: Session Manager is the best practice and recommended way by Amazon to manage your instances. Bastion hosts require remote access therefore exposing them to the internet. The most secure way is definitely session manager therefore answer A is correct imho.
Comment: I vote a
Comment: AWS Systems Manager Session Manager provides secure and auditable instance management without the need for any inbound connections or open ports. It allows you to manage your instances through an interactive one-click browser-based shell or through the AWS CLI. This means that you don't have to manage any SSH keys, and you don't have to worry about securing access to your instances as access is controlled through IAM policies.
Comment: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
Comment: Answer must be A
Comment: ANSWER - A AWS SESSION MANAGER IS CORRECT LEAST EFFORTS TO ACCESS LINUX SYSTEM IN AWS CONDOLE AND YOUR ARE ALREAADY LOGIN TO AWS. SO NO NEED FOR THE TOKEN OR OTHER STUFF DONE IN THE BACKGROUND BY AWS. MAKES SENESE.
Comment: Answer is A
Comment: Answer is A
Comment: A: is the solution for the company's requirements. Publishing data to Amazon Kinesis Data Streams can support ingestion rates as high as 1 MB/s and provide real-time data processing. Kinesis Data Analytics can query the ingested data in real-time with low latency, and the solution can scale as needed to accommodate increases in ingestion rates or querying needs. This solution also ensures minimal data loss in the event of an EC2 instance reboot since Kinesis Data Streams has a persistent data store for up to 7 days by default.
Comment: The fact they specifically mention "near real-time" twice tells me the correct answer is KDF. On top of which its easier to setup and maintain. KDS is really only needed if you need real-time. Also using redshift will mean permanent data retention. The data in A could be lost after a year. Redshift queries are slow but you're still querying near real-time data
Comment: You are very correct. see supporting link https://jayendrapatil.com/aws-kinesis-data-streams-vs-kinesis-firehose/#:~:text=vs%20Kine...-,Purpose,into%20AWS%20products%20for%20processing.
Comment: https://aws.amazon.com/pm/kinesis/?gclid=CjwKCAjwvIWzBhAlEiwAHHWgvRQuJmBubZDnO2GasDWwc2iBapfVD6GBeIgj2JV6qkldm-K_CmMzmxoCdCwQAvD_BwE&trk=ee1218b7-7c10-4762-97df-274836a44566≻_channel=ps&ef_id=CjwKCAjwvIWzBhAlEiwAHHWgvRQuJmBubZDnO2GasDWwc2iBapfVD6GBeIgj2JV6qkldm-K_CmMzmxoCdCwQAvD_BwE:G:s&s_kwcid=AL!4422!3!651510255264!p!!g!!kinesis%20stream!19836376690!149589222920
Comment: Option A is actually correct. The question ask for minimal data loss and that query of data should be near real time, not the ingestion. Kinesis data analytics is near real time. Recent changes to Redshift actually make B correct as well, but A is also correct.
Comment: Streaming ingestion provides low-latency, high-speed ingestion of stream data from Amazon Kinesis Data Streams and Amazon Managed Streaming for Apache Kafka into an Amazon Redshift provisioned or Amazon Redshift Serverless materialized view.[1] Option B mentions Kinesis Data Firehose (now just Firehose), so this won't work. Option A is the correct answer. [1]https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion.html
Comment: Comparison to other options: B. Kinesis Data Firehose with Redshift: While Redshift is scalable, it doesn't offer real-time querying capabilities. Data needs to be loaded into Redshift from Firehose, introducing latency. C. EC2 instance store with Kinesis Data Firehose and S3: Storing data in an EC2 instance store is not persistent and data will be lost during reboots. EBS volumes are more appropriate for persistent storage, but the architecture becomes more complex. D. EBS volume with ElastiCache and Redis: While ElastiCache offers fast in-memory storage, it's not designed for high-volume data ingestion like 1 MB/s. It might struggle with scalability and persistence.
Comment: I don't understand why people are giving wrong information in the QUESTION its clearly mentioned near Real Time Kinesis Data Streams is for Real time Where are Kinesis Datafirehose is for Near real time there for answer is B only
Comment: Read the question: near real-time querying of data.... it is more about real-time data query once the data is ingested, It does not mention how long time the data needs to be stored. A is better option. B introduces delay of data buffer before it can be queried in redshift
Comment: A is not correct because Kinesis can only store data up to 1 year. The solution need to support querying ALL data instead of "recent" data.
Comment: Says who? They want to "query ingested data in near-real time", it does not say anything about historical data.
Comment: A: is the solution for the company's requirements. Publishing data to Amazon Kinesis Data Streams can support ingestion rates as high as 1 MB/s and provide real-time data processing. Kinesis Data Analytics can query the ingested data in real-time with low latency, and the solution can scale as needed to accommodate increases in ingestion rates or querying needs. This solution also ensures minimal data loss in the event of an EC2 instance reboot since Kinesis Data Streams has a persistent data store for up to 7 days by default.
Comment: Publish data to Amazon Kinesis Data Streams, Use Kinesis Data Analytics to query the data
Comment: • Provide near-real-time data ingestion into Kinesis Data Streams with the ability to handle the 1 MB/s ingestion rate. Data would be stored redundantly across shards. • Enable near-real-time querying of the data using Kinesis Data Analytics. SQL queries can be run directly against the Kinesis data stream. • Minimize data loss since data is replicated across shards. If an EC2 instance is rebooted, the data stream is still accessible. • Scale seamlessly to handle varying ingestion and query rates.
Comment: Answer is A as it will provide a more streamlined solution. Using B (Firehose + Redshift) will involve sending the data to an S3 bucket first and then copying the data to Redshift which will take more time. https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html
Comment: Amazon Kinesis Data Firehose can deliver data in real-time to Amazon Redshift, making it immediately available for queries. Amazon Redshift, on the other hand, is a powerful data analytics service that allows fast and scalable querying of large volumes of data.
Comment: Redshift is a Data Warehouse in the first place, but the question says nothing about storing the data. They want to analyze it in near-real time, nobody says they need to store or access or analyze historical data.
Comment: • Provide near-real-time data ingestion into Kinesis Data Streams with the ability to handle the 1 MB/s ingestion rate. Data would be stored redundantly across shards. • Enable near-real-time querying of the data using Kinesis Data Analytics. SQL queries can be run directly against the Kinesis data stream. • Minimize data loss since data is replicated across shards. If an EC2 instance is rebooted, the data stream is still accessible. • Scale seamlessly to handle varying ingestion and query rates.
Comment: The other options would not fully meet the requirements: B) Kinesis Firehose + Redshift would introduce latency since data must be loaded from Firehose into Redshift before querying. Redshift would lack real-time capabilities. C) An EC2 instance store and Kinesis Firehose to S3 with Athena querying would risk data loss from instance store if an instance reboots. Athena querying data in S3 also lacks real-time capabilities. D) Using EBS storage, Kinesis Firehose to Redis and subscribing to Redis may provide near-real-time ingestion and querying but risks data loss if an EBS volume or EC2 instance fails. Recovery requires re-hydrating data from a backup which impacts real-time needs.
Comment: I voted A as well, although not 100% sure why B is not correct. I just selected what seems the most simple solution between A and B. Reason Kruasan gave "Redshift would lack real-time capabilities." This is not true. Redshift could do real-time. evidence https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/
Comment: ANSWER - A https://docs.aws.amazon.com/kinesisanalytics/latest/dev/what-is.html
Comment: near-real-time data querying = Kinesis analytics
Comment: Answer is A
Comment: https://aws.amazon.com/blogs/security/how-to-prevent-uploads-of-unencrypted-objects-to-amazon-s3/#:~:text=Solution%20overview
Comment: Thank you!
Comment: The x-amz-server-side-encryption header is used to specify the encryption method that should be used to encrypt objects uploaded to an Amazon S3 bucket. By updating the bucket policy to deny if the PutObject does not have this header set, the solutions architect can ensure that all objects uploaded to the bucket are encrypted.
Comment: Related reading because (as of Jan 2023) S3 buckets have encryption enabled by default. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html "If you require your data uploads to be encrypted using only Amazon S3 managed keys, you can use the following bucket policy. For example, the following bucket policy denies permissions to upload an object unless the request includes the x-amz-server-side-encryption header to request server-side encryption:"
Comment: To encrypt an object at the time of upload, you need to add a header called x-amz-server-side-encryption to the request to tell S3 to encrypt the object using SSE-C, SSE-S3, or SSE-KMS. The following code example shows a Put request using SSE-S3. https://aws.amazon.com/blogs/security/how-to-prevent-uploads-of-unencrypted-objects-to-amazon-s3/
Comment: The other options would not enforce encryption: A) Requiring an s3:x-amz-acl header does not mandate encryption. This header controls access permissions. B) Requiring an s3:x-amz-acl header set to private also does not enforce encryption. It only enforces private access permissions. C) Requiring an aws:SecureTransport header ensures uploads use SSL but does not specify that objects must be encrypted. Encryption is not required when using SSL transport.
Comment: To encrypt an object at the time of upload, you need to add a header called x-amz-server-side-encryption to the request to tell S3 to encrypt the object using SSE-C, SSE-S3, or SSE-KMS. The following code example shows a Put request using SSE-S3. https://aws.amazon.com/blogs/security/how-to-prevent-uploads-of-unencrypted-objects-to-amazon-s3/
Comment: Confusing question. It doesn't state clearly if the object needs to be encrypted at-rest or in-transit
Comment: That's true
Comment: I vote d
Comment: To ensure that all objects uploaded to an Amazon S3 bucket are encrypted, the solutions architect should update the bucket policy to deny any PutObject requests that do not have an x-amz-server-side-encryption header set. This will prevent any objects from being uploaded to the bucket unless they are encrypted using server-side encryption.
Comment: answer - D
Comment: Answer is D
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/amazon-s3-policy-keys.html
Comment: I've noticed there are a lot of questions about decoupling services and SQS is almost always the answer.
Comment: D SNS fan out
Comment: They don't look like real answers from the official exam...
Comment: Each option is badly worded: A: "generate the thumbnail and alert the user" doesn't sound sequential so could alert the user during, before or after the thumbnail generation whichever way you interpret it. B: this is sequential and won't alert until the steps are complete D: Could work without with the risk of notification loss so C is better but this is also ok
Comment: Safe answer is C but B is so badly worded that it can mean anything to confuse people. Step functions to use tiers. What if on of the step is to inform to the user and move on to next step. Anyway, I'll chose C for the exam as it is cleaner.
Comment: ... asynchronously dispatch ... => Amazon SQS
Comment: Asynchronous, Decoupling = Amazon Simple Queue Service
Comment: SQS is a fully managed message queuing service that can be used to decouple different parts of an application.
Comment: Answers B and D alert the user when thumbnail generation is complete. Answer C alerts the user through an application message that the image was received.
Comment: B: Use cases for Step Functions vary widely, from orchestrating serverless microservices, to building data-processing pipelines, to defining a security-incident response. As mentioned above, Step Functions may be used for synchronous and asynchronous business processes.
Comment: why not B?
Comment: Creating an Amazon Simple Queue Service (SQS) message queue and placing messages on the queue for thumbnail generation can help separate the image upload and thumbnail generation processes.
Comment: C The key here is "a faster response time to its users to notify them that the original image was received." i.e user needs to be notified when image was received and not after thumbnail was created.
Comment: A looks like the best way , but its essentially replacing the mentioned app , that's not the ask
Comment: Selected Answer: A https://docs.aws.amazon.com/lambda/latest/dg/with-s3-tutorial.html
Comment: C is the only one that makes sense
Comment: Use a custom AWS Lambda function to generate the thumbnail and alert the user. Lambda functions are well-suited for short-lived, stateless operations like generating thumbnails, and they can be triggered by various events, including image uploads. By using Lambda, the application can quickly confirm that the image was uploaded successfully and then asynchronously generate the thumbnail. When the thumbnail is generated, the Lambda function can send a message to the user to confirm that the thumbnail is ready. C proposes to use an Amazon Simple Queue Service (Amazon SQS) message queue to process image uploads and generate thumbnails. SQS can help decouple the image upload process from the thumbnail generation process, which is helpful for asynchronous processing. However, it may not be the most suitable option for quickly alerting the user that the image was received, as the user may have to wait until the thumbnail is generated before receiving a notification.
Comment: You understood C wrong. You place the message on the SQS queue and then you alert the user.
Comment: - Option A would not provide high availability. A single EC2 instance is a single point of failure. - Option B provides a scalable, highly available solution using serverless services. API Gateway and Lambda can scale automatically, and DynamoDB provides a durable data store. - Option C would expose the Lambda function directly to the public Internet, which is not a recommended architecture. API Gateway provides an abstraction layer and additional features like access control. - Option D requires configuring a VPN to AWS which adds complexity. It also saves the raw sensor data to S3, rather than processing it and storing the results.
Comment: Highly available = Serverless The readers send a message over HTTPS = HTTPS endpoint in Amazon API Gateway Process these messages from the sensors = AWS Lambda function
Comment: The correct answer is B. Create an HTTPS endpoint in Amazon API Gateway. Configure the API Gateway endpoint to invoke an AWS Lambda function to process the messages and save the results to an Amazon DynamoDB table. Here are the reasons why: API Gateway is a highly scalable and available service that can be used to create and expose RESTful APIs. Lambda is a serverless compute service that can be used to process events and data. DynamoDB is a NoSQL database that can be used to store data in a scalable and highly available way.
Comment: I vote B
Comment: It is option "B" Option "B" can provide a system with highly scalable, fault-tolerant, and easy to manage.
Comment: Deploy Amazon API Gateway as an HTTPS endpoint and AWS Lambda to process and save the messages to an Amazon DynamoDB table. This option provides a highly available and scalable solution that can easily handle large amounts of data. It also integrates with other AWS services, making it easier to analyze and visualize the data for the security team.
Comment: B is Correct
Comment: D is the correct answer Volume Gateway CACHED Vs STORED Cached = stores a subset of frequently accessed data locally Stored = Retains the ENTIRE ("all file types") in on prem data centre
Comment: Bad question. No RTO/RPO, so impossible to properly answer. They probably want to hear option D. Depending on RPO, option B is also an adequate solution (data remains immediately accessible without experiencing latency via existing infrastructure, backup to cloud for DR). Also, this option requires LESS changes to existing infra than A. Only argument against B is that VTLs are usually used for legacy DR solutions, not for new ones, where object storage such as S3 is usually supported natively.
Comment: Answer is C go argue somewhere.
Comment: A,B are wrong types of gateways for hundreds of TB of data that needs immediate access on-prem. C limits to 10TB. D provides access to all the files.
Comment: "Immediate access to all file types from the on-premises systems without experiencing latency" requirement is not met by C. Also the solution is meant for DR purposes, the primary storage for the data should remain on premises.
Comment: From chatGPT4 Considering the requirements of minimal infrastructure change, immediate file access, and low-latency, Option C: Provisioning an AWS Storage Gateway Volume Gateway (cached volume) with a 10 TB local cache, seems to be the most fitting solution. This setup aligns with the existing iSCSI setup and provides a local cache for low-latency access, while also configuring scheduled snapshots for disaster recovery. In the event of a disaster, restoring a snapshot to an Amazon EBS volume and attaching it to an Amazon EC2 instance as described in this option would align with the recovery objective.
Comment: ChatGPT is wrong. "Immediate access to all file types from the on-premises systems without experiencing latency" needs "stored volume" type. With "cached volume" not all data will be available locally.
Comment: pentium75 is right.
Comment: End users retain immediate access to all file types = Volume Gateway stored volume
Comment: "users retain immediate access to all file types" immediate cannot be cached -> D
Comment: dddddddd
Comment: Correct answer is Volume Gateway Stored which keeps all data on premises. To have immediate access to the data. Cached is for frequently accessed data only.
Comment: CCCCCCCCCCCCCCCC
Comment: The stored volume configuration stores the entire data set on-premises and asynchronously backs up the data to AWS. The cached volume configuration stores recently accessed data on-premises, and the remaining data is stored in Amazon S3 -that is why D is right
Comment: D is the correct answer Volume Gateway CACHED Vs STORED Cached = stores a data recentlly at local Stored = Retains the ENTIRE ("all file types") in on prem data centre
Comment: In the cached mode, your primary data is written to S3, while retaining your frequently accessed data locally in a cache for low-latency access. In the stored mode, your primary data is stored locally and your entire dataset is available for low-latency access while asynchronously backed up to AWS. Reference: https://aws.amazon.com/storagegateway/faqs/ Good luck.
Comment: It is stated the company wants to keep the data locally and have DR plan in cloud. It points directly to the volume gateway
Comment: "The company wants to ensure that end users retain immediate access to all file types from the on-premises systems " D is the correct answer.
Comment: all file types, NOT all files. Volume mode can not cache 100TBs.
Comment: https://docs.aws.amazon.com/storagegateway/latest/vgw/StorageGatewayConcepts.html Stored volumes can range from 1 GiB to 16 TiB in size and must be rounded to the nearest GiB. Each gateway configured for stored volumes can support up to 32 volumes and a total volume storage of 512 TiB (0.5 PiB).
Comment: all file types. Cached only save the most frecuently or lastest accesed. If you didn´t access any type for a long time, you will not cache it -> No immediate access
Comment: Also the solution is meant for DR purposes, it's not like they need more storage or so.
Comment: "The company wants to ensure that end users retain immediate access to all file types from the on-premises systems " This points to stored volumes..
Comment: To resolve the issue and provide proper permissions for users to access the protected content, the recommended solution is: A. Update the Amazon Cognito identity pool to assume the proper IAM role for access to the protected content. Explanation: Amazon Cognito provides authentication and user management services for web and mobile applications. In this scenario, the application is using Amazon Cognito as an identity provider to authenticate users and obtain JSON Web Tokens (JWTs). The JWTs are used to access protected resources stored in another S3 bucket. To grant users access to the protected content, the proper IAM role needs to be assumed by the identity pool in Amazon Cognito. By updating the Amazon Cognito identity pool with the appropriate IAM role, users will be authorized to access the protected content in the S3 bucket.
Comment: Option B is incorrect because updating the S3 ACL (Access Control List) will only affect the permissions of the application, not the users accessing the content. Option C is incorrect because redeploying the application to Amazon S3 will not resolve the issue related to user access permissions. Option D is incorrect because updating custom attribute mappings in Amazon Cognito will not directly grant users the proper permissions to access the protected content.
Comment: A is the best solution as it directly addresses the issue of permissions and grants authenticated users the necessary IAM role to access the protected content. A suggests updating the Amazon Cognito identity pool to assume the proper IAM role for access to the protected content. This is a valid solution, as it would grant authenticated users the necessary permissions to access the protected content.
Comment: IAM role is assinged to IAM users or groups or assumed by AWS service. So IAM role is given to AWS Cognito service which provides temporary AWS credentials to authenticated users. so technically When a user is authenticated by Cognito, they receive temporary credentials based on the IAM role tied to the Cognito identity pool. If this IAM role has permissions to access certain S3 buckets or objects, the authenticated user will be able to access those resources as allowed by the role. This service is used under the hood by Cognito to provide these temporary credentials. The credentials are limited in time and scope based on the permissions defined in the IAM role.
Comment: A. Update the Amazon Cognito identity pool to assume the proper IAM role for access to the protected content.
Comment: Services access other services via IAM Roles. Hence why updating AWS Cognito identity pool to assume proper IAM Role is the right solution.
Comment: Amazon Cognito identity pools assign your authenticated users a set of temporary, limited-privilege credentials to access your AWS resources. The permissions for each user are controlled through IAM roles that you create. https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html
Comment: A makes no sense - Cognito is not accessing the S3 resource. It just returns the JWT token that will be attached to the S3 request. D is the right answer, using custom attributes that are added to the JWT and used to grant permissions in S3. See https://docs.aws.amazon.com/cognito/latest/developerguide/using-attributes-for-access-control-policy-example.html for an example.
Comment: A says "Identity Pool" According to AWS: "With an identity pool, your users can obtain temporary AWS credentials to access AWS services, such as Amazon S3 and DynamoDB." So, answer is A
Comment: But even D requires setting up the permissions as bucket policy (as show in the shared example) which includes higher overhead than managing permissions attached to specific roles.
Comment: Services access other services via IAM Roles.
Comment: ANSWER - A https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-identity-pool.html You have to create an custom role such as read-only
Comment: Answer is A
Comment: AB A : Access Pattern for each object inconsistent, Infrequent Access B : Deleting Incomplete Multipart Uploads to Lower Amazon S3 Costs
Comment: B because Abort Incomplete Multipart Uploads Using S3 Lifecycle => https://aws.amazon.com/blogs/aws-cloud-financial-management/discovering-and-deleting-incomplete-multipart-uploads-to-lower-amazon-s3-costs/ A because The objects will be used less frequently after 30 days, but the access patterns for each object will be inconsistent => random access => S3 Intelligent-Tiering
Comment: AB for sure
Comment: If we consider these statements: 1. For the first 30 days after upload, the objects will be accessed frequently 2.The objects will be used less frequently after 30 days, but the access patterns for each object will be inconsistent 3.The company must optimize its S3 storage costs while maintaining high availability and resiliency of stored assets. 4.The company uses multipart upload in parallel by using S3 APIs and overwrites if the same object is uploaded again. Statements 1 and 2 cloudl be completed with option D and not A because datas are infrequently accessed only after 30 days. Due to usage of multipart upload, to meet requirement regarding cost optimization, option B will be used to clean up buckets uncompleted file parts(statements 3 & 4).
Comment: Because A & D address the main ask, there's no mention of cost optimization.
Comment: *Facepalm* It does ask for reducing the cost, A&B it is!
Comment: Because A & C address the main ask, there's no mention of cost optimization.
Comment: Not C ':D, I meant to say A&D. Added another vote for that one.
Comment: A as the access pattern for each object is inconsistent so let AWS AWS do the handling. B deals with multi-part duplication issues and saves money by deleting incomplete uploads C No mention of deleted object so this is a distractor D The objects will be accessed in unpredictable pattern so can't use this E Not HA compliant
Comment: Also, don't be confused by 30 days. The question has tricky wording: " The objects will be used less frequently after 30 days, but the access patterns for each object will be inconsistent" It does NOT say that objects will be accessed less frequently after 30 days. It says the access is unpredictable which means it could go up or down. Don't make assumptions.
Comment: C is nonsense E does not meet the "high availability and resiliency" requirement B is obvious (incomplete multipart uploads consume space -> cost money) The tricky part is A vs. D. However, 'inconsistent access patterns' are the primary use case for Intelligent-Tiering. There are probably objects that will never be accessed and that would be moved to Glacier Instant Retrieval by Intelligent-Tiering, thus the overall cost would be lower than with D.
Comment: bd https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html#sc-infreq-data-access =>S3 Standard-IA objects are resilient to the loss of an Availability Zone. This storage class offers greater availability and resiliency than the S3 One Zone-IA class
Comment: I wouldnt go with D since " the access patterns for each object will be inconsistent.", so we cannot move all assets to IA
Comment: incosistent access pattern brings more sense to use Intelligent-Tiering after 30 days which also covers infrequent access.
Comment: A. Move assets to S3 Intelligent-Tiering after 30 days. B. Configure an S3 Lifecycle policy to clean up incomplete multipart uploads.
Comment: should be A and B
Comment: Option A has not been mentioned for resiliency in S3, check the page: https://docs.aws.amazon.com/AmazonS3/latest/userguide/disaster-recovery-resiliency.html Therefore, I am with B & D choices.
Comment: Intelligent-Tiering just moves to Standard-IA or Glacier Instant Access based on access patterns. This does not affect resiliency.
Comment: A. Move assets to S3 Intelligent-Tiering after 30 days. B. Configure an S3 Lifecycle policy to clean up incomplete multipart uploads. Explanation: A. Moving assets to S3 Intelligent-Tiering after 30 days: This storage class automatically analyzes the access patterns of objects and moves them between frequent access and infrequent access tiers. Since the objects will be accessed frequently for the first 30 days, storing them in the frequent access tier during that period optimizes performance. After 30 days, when the access patterns become inconsistent, S3 Intelligent-Tiering will automatically move the objects to the infrequent access tier, reducing storage costs. B. Configuring an S3 Lifecycle policy to clean up incomplete multipart uploads: Multipart uploads are used for large objects, and incomplete multipart uploads can consume storage space if not cleaned up. By configuring an S3 Lifecycle policy to clean up incomplete multipart uploads, unnecessary storage costs can be avoided.
Comment: AD. B makes no sense because multipart uploads overwrite objects that are already uploaded. The question never says this is a problem.
Comment: Questions says to optimize cost and if incomplete multiparts are not aborted it will still use capacity on S3 Bucket thus increase unnecessary cost.
Comment: the following two actions to optimize S3 storage costs while maintaining high availability and resiliency of stored assets: A. Move assets to S3 Intelligent-Tiering after 30 days. This will automatically move objects between two access tiers based on changing access patterns and save costs by reducing the number of objects stored in the expensive tier. B. Configure an S3 Lifecycle policy to clean up incomplete multipart uploads. This will help to reduce storage costs by removing incomplete multipart uploads that are no longer needed.
Comment: Correct Answer A. Send the outbound connection from EC2 to Network Firewall. In Network Firewall, create stateful outbound rules to allow certain domains for software patch download and deny all other domains. https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering
Comment: Option A uses a network firewall which is overkill for instance-level rules.
Comment: Can't use URLs in outbound rule of security groups. URL Filtering screams Firewall.
Comment: Security Groups operate at the transport layer (Layer 4) of the OSI model and are primarily concerned with controlling traffic based on IP addresses, ports, and protocols. They do not have the capability to inspect or filter traffic based on URLs. The solution to restrict outbound internet traffic based on specific URLs typically involves using a proxy or firewall that can inspect the application layer (Layer 7) of the OSI model, where URL information is available. AWS Network Firewall operates at the network and application layers, allowing for more granular control, including the ability to inspect and filter traffic based on domain names or URLs. By configuring domain list rule groups in AWS Network Firewall, you can specify which URLs are allowed for outbound traffic. This option is more aligned with the requirement of allowing access to approved third-party software repositories based on their URLs.
Comment: https://aws.amazon.com/network-firewall/features/ "Web filtering: AWS Network Firewall supports inbound and outbound web filtering for unencrypted web traffic. For encrypted web traffic, Server Name Indication (SNI) is used for blocking access to specific sites. SNI is an extension to Transport Layer Security (TLS) that remains unencrypted in the traffic flow and indicates the destination hostname a client is attempting to access over HTTPS. In addition, **AWS Network Firewall can filter fully qualified domain names (FQDN).**" Always use an AWS product if the advertisement meets the use case.
Comment: AWS Network Firewall • Protect your entire Amazon VPC • From Layer 3 to Layer 7 protection • Any direction, you can inspect Traffic filtering: Allow, drop, or alert for the traffic that matches the rules, • Active flow inspection to intrusion prevention
Comment: D not possible?
Comment: ALB is for inbound traffic. D is not possible as it is suggesting to direct OUTBOUND traffic.
Comment: AWS network firewall is stateful, providing control and visibility to Layer 3-7 network traffic, thus cover the application too
Comment: Just tried on the console to set up an outbound rule, and URLs cannot be used as a destination. I will opt for A.
Comment: Implement strict inbound security group rules Configure an outbound security group rule to allow traffic only to the approved software repository URLs The key points: Highly sensitive EC2 instances in private subnet that can access only approved URLs Other internet access must be blocked Security groups act as a firewall at the instance level and can control both inbound and outbound traffic.
Comment: Security Groups work with CIDR ranges, not URLs.
Comment: Isnt private subnet not connectible to internet at all, unless with a NAT gateway?
Comment: We can't specifu URL in outbound rule of security group. Create free tier AWS account and test it.
Comment: CCCCCCCCCCC
Comment: Security Groups with IP ranges, not URLs
Comment: It can't be C. You cannot use URLs in the outbound rules of a security group.
Comment: Option C is the best solution to meet the requirements of this scenario. Implementing strict inbound security group rules that only allow traffic from approved sources can help secure the VPC network that hosts Amazon EC2 instances. Additionally, configuring an outbound rule that allows traffic only to the authorized software repositories on the internet by specifying the URLs will ensure that only approved third-party software repositories can be accessed from the EC2 instances. This solution does not require any additional AWS services and can be implemented using VPC security groups. Option A is not the best solution as it involves the use of AWS Network Firewall, which may introduce additional operational overhead. While domain list rule groups can be used to block all internet traffic except for the approved third-party software repositories, this solution is more complex than necessary for this scenario.
Comment: How do you use a Security Group to allow access to https://server.com/repoa while denying access to https://server.com/repob ? Security Groups work with IP ranges.
Comment: In the security group, only allow inbound traffic originating from the VPC. Then only allow outbound traffic with a whitelisted IP address. The question asks about blocking EC2 instances, which is best for security groups since those are at the EC2 instance level. A network firewall is at the VPC level, which is not what the question is asking to protect.
Comment: Is Security Group able to allow a specific URL? According to https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html, I cannot find such description.
Comment: Security Groups work with IP ranges, not URLs.
Comment: I am confused that It seems both options A and C are valid solutions.
Comment: Same here - why is C not a valid option?
Comment: Because in this case, the session is initialized from inside
Comment: And it is easier to do it at the level
Comment: And it is easier to do it at the VPC level
Comment: I think C is in private subnet. Even with security group, it could not go public to download the software.
Comment: C is not valid. Security groups can allow only traffic from specific ports and/or IPs, you can't use an URL. Correct answer is A
Comment: Answer - A https://aws.amazon.com/premiumsupport/knowledge-center/ec2-al1-al2-update-yum-without-internet/
Comment: Although the answer is A, the link you provided here is not related to this question. The information about "Network Firewall" and how it can help this issue is here: https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering (thanks to "@Bhawesh" to provide the link in their answer)
Comment: The auto-scaling would increase the rate at which sales requests are "processed", whereas a SQS will ensure messages don't get lost. If you were at a fast food restaurant with a long line with 3 cash registers, would you want more cash registers or longer ropes to handle longer lines? Same concept here.
Comment: ensure that all the requests are processed successfully? doesn't mean more quickly
Comment: Hell true: I'd rather combine the both options: a SQS + auto-scaled bound to the length of the queue.
Comment: As an architecture, it is not possible to add more backend workers (it is part of the HR and boss's job, not for architecture design the solution). So when the demand surge, the only correct choice is to buffer them using SQS so that workers can take their time to process it successfully
Comment: "ensure that all the requests are processed successfully?" we want to ensure success not the speed, even in the auto-scaling, there is the chance for the failure of the request but not in SQS- if it is failed in sqs it is sent back to the queue again and new consumer will pick the request.
Comment: B doesn't fit because Auto Scaling alone does not guarantee that all requests will be processed successfully, which the question clearly asks for. D ensures that all messages are processed.
Comment: The problem states that the application consists of "static and dynamic front-end content." Static content typically includes cacheable resources such as HTML, CSS, and image files. Therefore, from this statement, one can infer that caching static content using CloudFront would improve performance. In other words, the mention of "static content" in the problem itself leads to the conclusion that CloudFront should be added for static content. Additionally, the problem mentions "asynchronously processed backend workers." Asynchronous processing is well-suited for services like SQS, which can improve efficiency by handling dynamic requests that do not require immediate processing. The mention of "successfully processing all requests" also suggests that SQS is needed to ensure that all requests are handled properly. Therefore, the correct answer is D.
Comment: Important question to answer D. Can you connect the website with SQS directly? How do you control access to who can put messages to SQS? I have never seen such a situation it has to be at least behind API gateway. So that conclusion brings me to answer B, application also can process async everything without SQS.
Comment: I chose D because I love SQS! These questions are hammering SQS in every solution as a "protagonist" that saves the day. AC are clearly useless B can work but D is better because of SQS being better than EC2 scaling. The other part is that backend workers process the request asynchronously therefore a queue is better.
Comment: A and C don't solve anything so ignore them. Between B and D, D guarantees the scaling via SQS and order processing. B can also do that but it is not guaranteed that EC2 scaling will work to process the order. As usual, I suspect that this "brain dump" may be missing critical wording to differentiate between the options so read carefully in the exam.
Comment: There are two components that we need * Frontend: Hosted on S3, performance can be increased with CloudFront * Backend: There's no reason to process all the orders instantly, so we should decouple the processing from the API which we do with SQS Thus D, CloudFront + SQS
Comment: And as others said, B might speed up the processing or reduce the number of lost orders, but we need to make sure that "ALL requests are processed successfully", NOT that "less requests are lost".
Comment: I picked B before I read D option. Read the question again, it concerns:asynchronous processing of sales requests, Option D seems to align more closely with the requirements. So the requirement is ensuring all requests are processed successfully which means no request would be missed. So D is better option
Comment: Amazon SQS will make sure that the requests are stored and didn't get lost. After that the workers asynchronously will process the requests. I would go for D
Comment: Technically both option B and D would work. But, there's a need to process requests asynchronously, hence decoupling, hence Amazon SQS. I will settle with option D.
Comment: D is correct.
Comment: D is correct.
Comment: An SQS queue acts as a buffer between the frontend (website) and backend (API). Web requests can dump messages into the queue at a high throughput, then the queue handles delivering those messages to the API at a controlled rate that it can sustain. This prevents the API from being overwhelmed.
Comment: Options A and B would help by scaling out more instances, however, this may not scale quickly enough and still risks overwhelming the API. Caching parts of the dynamic content (option C) may help but does not provide the buffering mechanism that a queue does.
Comment: D make sens
Comment: D makes more sense
Comment: There is no clarity on what the asynchronous process is but D makes more sense if we want to process all requests successfully. The way the question is worded it looks like the msgs->SQS>ELB/Ec2. This ensures that the messages are processed but may be delayed as the load increases.
Comment: although i agree with B for better performance. but i choose 'D' as question request to ensure that all the requests are processed successfully.
Comment: Amazon Inspector is a security assessment service that automatically assesses applications for vulnerabilities or deviations from best practices. It can be used to scan the EC2 instances for software vulnerabilities. AWS Systems Manager Patch Manager can be used to patch the EC2 instances on a regular schedule. Together, these services can provide a solution that meets the requirements of running regular security scans and patching EC2 instances on a regular schedule. Additionally, Patch Manager can provide a report of each instance's patch status.
Comment: A handy reference page for such questions is: https://aws.amazon.com/products/security/ Amazon Inspector = vulnerability detection = patching https://aws.amazon.com/inspector/
Comment: dddddddddd
Comment: Inspecter is for EC2 instances and network accessibility of those instances https://portal.tutorialsdojo.com/forums/discussion/difference-between-security-hub-detective-and-inspector/
Comment: Amazon Inspector is a security assessment service that helps improve the security and compliance of applications deployed on Amazon Web Services (AWS). It automatically assesses applications for vulnerabilities or deviations from best practices. Amazon Inspector can be used to identify security issues and recommend fixes for them. It is an ideal solution for running regular security scans across a large fleet of EC2 instances. AWS Systems Manager Patch Manager is a service that helps you automate the process of patching Windows and Linux instances. It provides a simple, automated way to patch your instances with the latest security patches and updates. Patch Manager helps you maintain compliance with security policies and regulations by providing detailed reports on the patch status of your instances.
Comment: Amazon Inspector for EC2 https://aws.amazon.com/vi/inspector/faqs/?nc1=f_ls Amazon system manager Patch manager for automates the process of patching managed nodes with both security-related updates and other types of updates. http://webcache.googleusercontent.com/search?q=cache:FbFTc6XKycwJ:https://medium.com/aws-architech/use-case-aws-inspector-vs-guardduty-3662bf80767a&hl=vi≷=kr&strip=1&vwsrc=0
Comment: answer - D https://aws.amazon.com/inspector/faqs/
Comment: D as AWS Systems Manager Patch Manager can patch the EC2 instances.
Comment: A: Enable encryption B: KMS is for storage and doesn't directly integrate to DB without further work C and D are for data encryption in transit not at rest
Comment: Actually, D is total nonsense and no idea what it is saying
Comment: KMS only generates and manages encryption keys. That's it. That's all it does. It's a fundamental service that you as well as other AWS Services (like Secrets Manager) use it to encrypt or decrypt. Key Management Service. Secrets Manager is for database connection strings. upvoted 3 times
Comment: OK, but why not B???
Comment: KMS only generates and manages encryption keys. That's it. That's all it does. It's a fundamental service that you as well as other AWS Services (like Secrets Manager) use it to encrypt or decrypt. Secrets Manager stores actual secrets like passwords, pass phrases, and anything else you want encrypted. SM uses KMS to encrypt its secrets, it would be circular to get an encryption key from KMS to use SM to encrypt the encryption key.
Comment: ANSWER - A
Comment: A for sure
Comment: A is 100% Crt
Comment: Key Management Service. Secrets Manager is for database connection strings.
Comment: A is the correct solution to meet the requirement of encrypting the data at rest. To encrypt data at rest in Amazon RDS, you can use the encryption feature of Amazon RDS, which uses AWS Key Management Service (AWS KMS). With this feature, Amazon RDS encrypts each database instance with a unique key. This key is stored securely by AWS KMS. You can manage your own keys or use the default AWS-managed keys. When you enable encryption for a DB instance, Amazon RDS encrypts the underlying storage, including the automated backups, read replicas, and snapshots.
Comment: AWS Key Management Service (KMS) is used to manage the keys used to encrypt and decrypt the data.
Comment: Option A
Comment: A. Create a key in AWS Key Management Service (AWS KMS). Enable encryption for the DB instances is the correct answer to encrypt the data at rest in Amazon RDS DB instances. Amazon RDS provides multiple options for encrypting data at rest. AWS Key Management Service (KMS) is used to manage the keys used to encrypt and decrypt the data. Therefore, a solution architect should create a key in AWS KMS and enable encryption for the DB instances to encrypt the data at rest.
Comment: ANSWER - A https://docs.aws.amazon.com/whitepapers/latest/efs-encrypted-file-systems/managing-keys.html
Comment: A. Create a key in AWS Key Management Service (AWS KMS). Enable encryption for the DB instances. https://www.examtopics.com/discussions/amazon/view/80753-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Don't mix up between Mbps and Mbs. The proper calculation is: 10 MB/s x 86,400 seconds per day x 30 days/8 = 3,402,000 MB or approximately 3.4 TB
Comment: Honestly, the company has bigger problem with that slow connection :) 30 days is the first clue so you can get snowball shipped and sent back (5 days each way)
Comment: aws snowball은 대용량 데이터 이전하기 위한 것 입니다.
Comment: (15/8) = 1.875 MB/s 1.875 MB/s x 0.7 = 1.3125 (70% NW utilization) MB/s 1.3125 MB/s x 3600 = 4725 MB (MB per 1 hour) 4725 x 24 = 113400 MB per 1 full day (24h) 113400 x 30 = 3402000 MB for 30 days 3402000 / 1024 = 3322.265625 GB for 30 days 3322.265625 / 1024 ~ 3.24 TB for 30 days => not enough for NW => Snowball which is A
Comment: I wont try to think to much about it, AWS Snowball was designed for this
Comment: ° 15 Mbps bandwidth with 70% max utilization limits the effective bandwidth to 10.5 Mbps or 1.31 MB/s. ° 20 TB of data at 1.31 MB/s would take approximately 193 days to transfer over the network. ° This far exceeds the 30 day requirement. ° AWS Snowball provides a physical storage device that can be shipped to the data center. Up to 80 TB can be loaded onto a Snowball device and shipped back to AWS. This allows the 20 TB of data to be transferred much faster by shipping rather than over the limited network bandwidth. ° Snowball uses tamper-resistant enclosures and 256-bit encryption to keep the data secure during transit. ° The data can be imported into Amazon S3 or Amazon Glacier once the Snowball is received by AWS.
Comment: 10 MB/s x 86,400 seconds per day x 30 days = 25,920,000 MB or approximately 25.2 TB That's how much you can transfer with a 10 Mbps link (roughly 70% of the 15 Mbps connection). With a consistent connection of 8~ Mbps, and 30 days, you can upload 20 TB of data. My math says B, my brain wants to go with A. Take your pick.
Comment: 15 Mbps * 0.7 = 1.3125 MB/s and 1.3125 * 86,400 * 30 = 3.402.000 MB Answer A is correct.
Comment: How can 15 * 0.7 be 1.3125 LMAO
Comment: OMG it was Mbps! Not MBps. You are right! awesome!!!
Comment: 3,402,000
Comment: Aws snowball
Comment: A is 100% Crt
Comment: AWS Snowball
Comment: Option a
Comment: ANSWER - A https://docs.aws.amazon.com/snowball/latest/ug/whatissnowball.html
Comment: option A
Comment: This solution addresses the need for secure access to confidential and sensitive files, as well as the increase in remote usage. Migrating the files to Amazon FSx for Windows File Server provides a scalable, fully managed file storage solution in the AWS Cloud that is accessible from on-premises and cloud environments. Integration with the on-premises Active Directory allows for a consistent user experience and centralized access control. AWS Client VPN provides a secure and managed VPN solution that can be used by employees to access the files securely.
Comment: My money is on B, but it's still not mentioned that the customer used an on-prem Active Directory.
Comment: C has "signed URL", everyone who has the URL could download. Plus, only B ensure the "must be downloaded securely" part by using VPN.
Comment: Windows file server = Amazon FSx for Windows File Server file system Files can be accessed only by authorized users = On-premises Active Directory
Comment: Remember: The file server is running out of capacity.
Comment: But then how do you download the files to user's machine in a secure way?
Comment: That's why we're using FSX for Windows File Server in AWS. "Signed URL to allow download" would allow everyone who has the URL to download the files, but we must "ensure that the files can be accessed only by authorized users". Plus, the "private VPC endpoint" is not really of use here, it's still S3 and the users are not in AWS.
Comment: B is the correct answer
Comment: B is the best solution for the given requirements. It provides a secure way for employees to access confidential and sensitive files from anywhere using AWS Client VPN. The Amazon FSx for Windows File Server file system is designed to provide native support for Windows file system features such as NTFS permissions, Active Directory integration, and Distributed File System (DFS). This means that the company can continue to use their on-premises Active Directory to manage user access to files.
Comment: B is the correct answer
Comment: Answer - B 1- https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html 2- https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-storage-capacity.html
Comment: B Amazon FSx for Windows File Server file system
Comment: 'On the first day of every month at midnight' = Scheduled scaling policy
Comment: By configuring a scheduled scaling policy, the EC2 Auto Scaling group can proactively launch additional EC2 instances before the CPU utilization peaks to 100%. This will ensure that the application can handle the workload during the month-end financial calculation batch, and avoid any disruption or downtime. Configuring a simple scaling policy based on CPU utilization or adding Amazon CloudFront distribution or Amazon ElastiCache will not directly address the issue of handling the monthly peak workload.
Comment: If the scaling were based on CPU or memory, it requires a certain amount of time above that threshhold, 5 minutes for example. That would mean the CPU would be at 100% for five minutes.
Comment: C: Configure an EC2 Auto Scaling scheduled scaling policy based on the monthly schedule is the best option because it allows for the proactive scaling of the EC2 instances before the monthly batch run begins. This will ensure that the application is able to handle the increased workload without experiencing downtime. The scheduled scaling policy can be configured to increase the number of instances in the Auto Scaling group a few hours before the batch run and then decrease the number of instances after the batch run is complete. This will ensure that the resources are available when needed and not wasted when not needed. The most appropriate solution to handle the increased workload during the monthly batch run and avoid downtime would be to configure an EC2 Auto Scaling scheduled scaling policy based on the monthly schedule.
Comment: Scheduled scaling policies allow you to schedule EC2 instance scaling events in advance based on a specified time and date. You can use this feature to plan for anticipated traffic spikes or seasonal changes in demand. By setting up scheduled scaling policies, you can ensure that you have the right number of instances running at the right time, thereby optimizing performance and reducing costs. To set up a scheduled scaling policy in EC2 Auto Scaling, you need to specify the following: Start time and date: The date and time when the scaling event should begin. Desired capacity: The number of instances that you want to have running after the scaling event. Recurrence: The frequency with which the scaling event should occur. This can be a one-time event or a recurring event, such as daily or weekly.
Comment: C is the correct answer as traffic spike is known
Comment: ANSWER - C https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html
Comment: C as the schedule of traffic spike is known beforehand.
Comment: SFTP, FTP - think "Transfer" during test time
Comment: LEAST operational overhead => A, D is much more operational overhead
Comment: SFTP, No changes to the customer's application? = AWS Transfer Family
Comment: Transfer family is used for SFTP
Comment: SFTP -> transfer family
Comment: A no doubt. Why the system gives B as the correct answer?
Comment: just A
Comment: AWS Transfer Family
Comment: AWS Transfer Family is a fully managed service that allows customers to transfer files over SFTP, FTPS, and FTP directly into and out of Amazon S3. It eliminates the need to manage any infrastructure for file transfer, which reduces operational overhead. Additionally, the service can be configured to use an existing Active Directory for authentication, which means that no changes need to be made to the customer's application.
Comment: Transfer family is used for SFTP
Comment: using AWS Batch to LEAST operational overhead and have SFTP to no changes to the customer's application https://aws.amazon.com/vi/blogs/architecture/managed-file-transfer-using-aws-transfer-family-and-amazon-s3/
Comment: A. Set up AWS Transfer Family with SFTP for Amazon S3. Configure integrated Active Directory authentication. https://docs.aws.amazon.com/transfer/latest/userguide/directory-services-users.html
Comment: readed the question 5 times, didn't understood a thing :(
Comment: Me too((( terrible question
Comment: Me too
Comment: the same here!
Comment: Enabling Amazon Elastic Block Store (Amazon EBS) fast snapshot restore on a snapshot allows you to quickly create a new Amazon Machine Image (AMI) from a snapshot, which can help reduce the initialization latency when provisioning new instances. Once the AMI is provisioned, you can replace the AMI in the Auto Scaling group with the new AMI. This will ensure that new instances are launched from the updated AMI and are able to meet the increased demand quickly.
Comment: The question wording is pretty weird but the only thing of value is latency during initialisation which makes B the correct option. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html A only helps with creating the AMI C and D will probably work (ambiguous language) but won't handle initialising latency issues.
Comment: Fast Snapshot Restore (FSR) • Force full initialization of snapshot to have no latency on the first use
Comment: "Fast snapshot restore" = pre-warmed snapshot AMI from such a snapshot is pre-warmed AMI
Comment: Amazon Data Lifecycle Manager (DLM) is a feature of Amazon EBS that automates the creation, retention, and deletion of snapshots, which are used to back up your Amazon EBS volumes. With DLM, you can protect your data by implementing a backup strategy that aligns with your business requirements. You can create lifecycle policies to automate snapshot management. Each policy includes a schedule of when to create snapshots, a retention rule with a defined period to retain each snapshot, and a set of Amazon EBS volumes to assign to the policy. This service helps simplify the management of your backups, ensure compliance, and reduce costs.
Comment: We're not asked to "simplify the management of our backups, ensure compliance, and reduce costs", we're asked to "provide minimum initialization latency" for an auto-scaling group.
Comment: Sorry, its "C" and not "D"
Comment: b is correct
Comment: B. Enable Amazon Elastic Block Store (Amazon EBS) fast snapshot restore on a snapshot. Provision an AMI by using the snapshot. Replace the AMI in the Auto Scaling group with the new AMI. Here's the reasoning: Amazon EBS Fast Snapshot Restore: This feature allows you to quickly create new EBS volumes (and subsequently AMIs) from snapshots. Fast Snapshot Restore optimizes the initialization process by pre-warming the snapshots, reducing the time it takes to create volumes from those snapshots. Provision an AMI using the snapshot: By using fast snapshot restore, you can efficiently provision an AMI from the pre-warmed snapshot, minimizing the initialization latency. Replace the AMI in the Auto Scaling group: This allows you to update the instances in the Auto Scaling group with the new AMI efficiently, ensuring that the new instances are launched with minimal delay.
Comment: Option A (Use aws ec2 register-image command and AWS Step Functions): While this approach can be used to automate the creation of an AMI and update the Auto Scaling group, it may not offer the same level of optimization for initialization latency as Amazon EBS fast snapshot restore. Option C (Enable AMI creation and define lifecycle rules in Amazon Data Lifecycle Manager, create a Lambda function): While Amazon DLM can help manage the lifecycle of your AMIs, it might not provide the same level of speed and responsiveness needed for sudden increases in demand. Option D (Use Amazon EventBridge and AWS Backup): AWS Backup is primarily designed for backup and recovery, and it might not be as optimized for quickly provisioning instances in response to sudden demand spikes. EventBridge can be used for event-driven architectures, but in this context, it might introduce unnecessary complexity.
Comment: Enable Amazon Elastic Block Store (Amazon EBS) fast snapshot restore on a snapshot. Provision an AMI by using the snapshot. Replace the AMI in the Auto Scaling group with the new AMI
Comment: Pleaw3 reword 5he question. Can not understand a thing!
Comment: Enable EBS fast snapshot restore on a snapshot Create an AMI from the snapshot Replace the AMI used by the Auto Scaling group with this new AMI The key points: ° Need to launch large EC2 instances quickly from an AMI in an Auto Scaling group ° Looking to minimize instance initialization latency
Comment: B most def
Comment: B: "EBS fast snapshot restore": minimizes initialization latency. This is a good choice.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html
Comment: Keyword, minimize initilization latency == snapshot. A and B have snapshots in them, but B is the one that makes sense. C has DLP that can create machines from AMI, but that does not talk about latency and snapshots.
Comment: Enabling Amazon Elastic Block Store (Amazon EBS) fast snapshot restore on a snapshot allows for rapid restoration of EBS volumes from snapshots. This reduces the time required to create an AMI from a snapshot, which is useful for quickly provisioning large Amazon EC2 instances. Provisioning an AMI by using the fast snapshot restore feature is a fast and efficient way to create an AMI. Once the AMI is created, it can be replaced in the Auto Scaling group without any downtime or disruption to running instances.
Comment: Enabling Amazon Elastic Block Store (Amazon EBS) fast snapshot restore on a snapshot allows you to quickly create a new Amazon Machine Image (AMI) from a snapshot, which can help reduce the initialization latency when provisioning new instances. Once the AMI is provisioned, you can replace the AMI in the Auto Scaling group with the new AMI. This will ensure that new instances are launched from the updated AMI and are able to meet the increased demand quickly.
Comment: AWS Secrets Manager allows you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. With this service, you can automate the rotation of secrets, such as database credentials, on a schedule that you choose. The solution allows you to create a new secret with the appropriate credentials and associate it with the Aurora DB cluster. You can then configure a custom rotation period of 14 days to ensure that the credentials are automatically rotated every two weeks, as required by the IT security guidelines. This approach requires the least amount of operational effort as it allows you to manage secrets centrally without modifying your application code or infrastructure.
Comment: Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days
Comment: Use AWS Secrets Manager to store the Aurora credentials as a secret Encrypt the secret with a KMS key Configure 14 day automatic rotation for the secret Associate the secret with the Aurora DB cluster The key points: Aurora MySQL credentials must be encrypted and rotated every 14 days Want to minimize operational effort
Comment: A: AWS Secrets Manager. Simply this supported rotate feature, and secure to store credentials instead of EFS or S3.
Comment: Voting A
Comment: A proposes to create a new AWS KMS encryption key and use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Then, the secret will be associated with the Aurora DB cluster, and a custom rotation period of 14 days will be configured. AWS Secrets Manager will automate the process of rotating the database credentials, which will reduce the operational effort required to meet the IT security guidelines.
Comment: Answer is A To implement password rotation lifecycles, use AWS Secrets Manager. You can rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle using Secrets Manager. https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-manager-rotate-credentials-amazon-rds-database-types-oracle/
Comment: A https://www.examtopics.com/discussions/amazon/view/59985-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: i hate this kind of question
Comment: Using Cache required huge changes in the application. Several things need to change to use cache in front of the DB in the application. So, option B is not correct. Aurora will help to reduce replication lag for read replica
Comment: You need to read the question carefully. The solutions architect must minimize changes to the application code = therefore A If this question without this statement, B will be a better choice.
Comment: minimize ongoing operational overhead = Not B Using ElastiCache require app change
Comment: AWS Aurora and Native Functions are least application changes while providing better performance and minimum latency. https://aws.amazon.com/rds/aurora/faqs/ B, C, D require lots of changes to the application so relatively speaking A is least code change and least maintenance/operational overhead.
Comment: A: Minimal changes to the application code, < 1 second lag B: Does not address the replication lag issue at all, requires code changes and adds overhead C: Moving from managed RDS to self-managed database on EC2 is ADDING, not minimizing, overhead, PLUS it does not address the replication lag issue D: DynamoDB is a NoSQL DB, would require MASSIVE changes to application code and probably even application logic
Comment: imho, B is not valid because it involves extra coding and the question specifically mentions no more coding. Therefore, replacing the current db with another one is not considered as more coding.
Comment: Migrate the database to Amazon Aurora MySQL. Replace the read replicas with Aurora Replicas, and configure Aurora Auto Scaling. Replace the stored procedures with Aurora MySQL native functions
Comment: Migrate the RDS MySQL database to Amazon Aurora MySQL Use Aurora Replicas for read scaling instead of RDS read replicas Configure Aurora Auto Scaling to handle load spikes Replace stored procedures with Aurora MySQL native functions
Comment: First, Elasticache involves heavy change on application code. The question mentioned that "he solutions architect must minimize changes to the application code". Therefore B is not suitable and A is more appropriate for the question requirement.
Comment: ... but migrating their ENTIRE prod database and its replicas to a new platform is not a heavy change?
Comment: Why not B? Please explain to me.
Comment: It wouldn't have the most up to date info since it must no lag in relation to the main DB
Comment: How would adding a cache "reduce the replication lag" between the primary instance and the read replicas? Plus, it would require "changes to the application code" that we want to avoid. The "AWS Lambda functions" would create "ongoing operational overhead" that we're also asked to avoid.
Comment: Option A is the most appropriate solution for reducing replication lag without significant changes to the application code and minimizing ongoing operational overhead. Migrating the database to Amazon Aurora MySQL allows for improved replication performance and higher scalability compared to Amazon RDS for MySQL. Aurora Replicas provide faster replication, reducing the replication lag, and Aurora Auto Scaling ensures that there are enough Aurora Replicas to handle the incoming traffic. Additionally, Aurora MySQL native functions can replace the stored procedures, reducing the load on the database and improving performance. Option B is not the best solution since adding an ElastiCache for Redis cluster does not address the replication lag issue, and the cache may not have the most up-to-date information. Additionally, replacing the stored procedures with AWS Lambda functions adds additional complexity and may not improve performance.
Comment: I agree with your explanation. Additionally, considering the requirement that "the read replicas must lag no more than 1 second behind the primary DB instance," it's crucial to ensure that Elasticache for Redis also maintains this tight synchronization window. This implies that the main RDS instance would need to synchronize an additional database, potentially exacerbating lag during peak times rather than alleviating it.
Comment: a,b are confusing me.. i would like to go with b..
Comment: Option B is incorrect because it suggests using ElastiCache for Redis as a caching layer in front of the database, but this would not necessarily reduce the replication lag on the read replicas. Additionally, it suggests replacing the stored procedures with AWS Lambda functions, which may require significant changes to the application code.
Comment: Yes and moreover Redis requires app refactoring which is a solid operational overhead
Comment: By using ElastiCache you avoid a lot of common issues you might encounter. ElastiCache is a database caching solution. ElastiCache Redis per se, supports failover and Multi-AZ. And Most of all, ElastiCache is well suited to place in front of RDS. Migrating a database such as option A, requires operational overhead.
Comment: Database migration is one-time work, NOT "operational overhead". Plus, RDS for MySQL to Aurora with MySQL compatibility is not a big deal, and "minimizes changes to the application code" as requested.
Comment: Aurora can have up to 15 read replicas - much faster than RDS https://aws.amazon.com/rds/aurora/
Comment: " As a result, all Aurora Replicas return the same data for query results with minimal replica lag. This lag is usually much less than 100 milliseconds after the primary instance has written an update " Reference: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html
Comment: You can invoke an Amazon Lambda function from an Amazon Aurora MySQL-Compatible Edition DB cluster with the "native function".... https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html
Comment: Answer - A https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.html --------------------------------------------------------------------------------------- You can scale reads for your Amazon RDS for PostgreSQL DB instance by adding read replicas to the instance. As with other Amazon RDS database engines, RDS for PostgreSQL uses the native replication mechanisms of PostgreSQL to keep read replicas up to date with changes on the source DB. For general information about read replicas and Amazon RDS, see Working with read replicas.
Comment: I originally went for D but now I think B is correct. D is active-active cluster so whereas B is active-passive (headless cluster) so it is cheaper than D. https://aws.amazon.com/blogs/database/achieve-cost-effective-multi-region-resiliency-with-amazon-aurora-global-database-headless-clusters/
Comment: Answer - A https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html ----------------------------------------------------------------------------- Before you begin Before you can create an Aurora MySQL DB cluster that is a cross-Region read replica, you must turn on binary logging on your source Aurora MySQL DB cluster. Cross-region replication for Aurora MySQL uses MySQL binary replication to replay changes on the cross-Region read replica DB cluster.
Comment: The question states " The DR plan must replicate data to a "secondary" AWS Region." In addition to Aurora Replicas, you have the following options for replication with Aurora MySQL: Aurora MySQL DB clusters in different AWS Regions. You can replicate data across multiple Regions by using an Aurora global database. For details, see High availability across AWS Regions with Aurora global databases You can create an Aurora read replica of an Aurora MySQL DB cluster in a different AWS Region, by using MySQL binary log (binlog) replication. Each cluster can have up to five read replicas created this way, each in a different Region. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html
Comment: The question is asking for the most cost-effective solution. Aurora global databases are more expensive. https://aws.amazon.com/rds/aurora/pricing/
Comment: On this same URL you provided, there is a note highlighted, stating the following: "Replication from the primary DB cluster to all secondaries is handled by the Aurora storage layer rather than by the database engine, so lag time for replicating changes is minimal—typically, less than 1 second. Keeping the database engine out of the replication process means that the database engine is dedicated to processing workloads. It also means that you don't need to configure or manage the Aurora MySQL binlog (binary logging) replication." So, answer should be A
Comment: Correction: So, answer should be D
Comment: Aurora Global Databases offer a cost-effective way to replicate data to a secondary region for disaster recovery. By removing the secondary DB instance after setup, you only pay for storage and minimal compute resources.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database.advantages
Comment: Wrong, while D will work, B is cheaper. This question is about DR, not cross region scaling
Comment: B is more cost-effective however because this is DR so when the region fails => still need a DB to fail over and if setting up a DB from snapshot at the time of failure will be risky => D is the answer
Comment: "Achieve cost-effective multi-Region resiliency with Amazon Aurora Global Database headless clusters" is exactly the topic here. "A headless secondary Amazon Aurora database cluster is one without a database instance. This type of configuration can lower expenses for an Aurora global database." https://aws.amazon.com/blogs/database/achieve-cost-effective-multi-region-resiliency-with-amazon-aurora-global-database-headless-clusters/
Comment: shd be D i guess .. . Migrating the database to Amazon Aurora MySQL allows for improved replication performance and higher scalability compared to Amazon RDS for MySQL. Aurora Replicas provide faster replication, reducing the replication lag, and Aurora Auto Scaling ensures that there are enough Aurora Replicas to handle the incoming traffic. Additionally, Aurora MySQL native functions can replace the stored procedures, reducing the load on the database and improving performance. Option B is not the best solution since adding an ElastiCache for Redis cluster does not address the replication lag issue, and the cache may not have the most up-to-date information. Additionally, replacing the stored procedures with AWS Lambda functions adds additional complexity and may not improve performance.
Comment: This is about a different question
Comment: Set up an Aurora global database for the DB cluster. Specify a minimum of one DB instance in the secondary Region
Comment: should be B for most cost effective solution. see the link - Achieve cost-effective multi-Region resiliency with Amazon Aurora Global Database headless clusters https://aws.amazon.com/blogs/database/achieve-cost-effective-multi-region-resiliency-with-amazon-aurora-global-database-headless-clusters/
Comment: MOST cost-effective --> B See section "Creating a headless Aurora DB cluster in a secondary Region" on the link https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html "Although an Aurora global database requires at least one secondary Aurora DB cluster in a different AWS Region than the primary, you can use a headless configuration for the secondary cluster. A headless secondary Aurora DB cluster is one without a DB instance. This type of configuration can lower expenses for an Aurora global database. In an Aurora DB cluster, compute and storage are decoupled. Without the DB instance, you're not charged for compute, only for storage. If it's set up correctly, a headless secondary's storage volume is kept in-sync with the primary Aurora DB cluster."
Comment: upvoted your message, but still think D is correct. Because the question is to design a DR plan.In case of DR, B need to create an instance in DR region manually.
Comment: D: With Amazon Aurora Global Database, you pay for replicated write I/Os between the primary Region and each secondary Region (in this case 1). Not A because it achieves the same, would be equally costly and adds overhead.
Comment: CCCCCC
Comment: I think Amazon is looking for D here. I don' think A is intended because that would require knowledge of MySQL, which isn't what they are testing us on. Not option C because the question states large volume. If the volume were low, then DMS would be better. This question is not a good question.
Comment: very true. Amazon wanna everyone to use AWS, why do they sell for MySQL?
Comment: D provides automatic replication
Comment: D provides automatic replication to a secondary Region through the Aurora global database feature. This feature provides automatic replication of data across AWS Regions, with the ability to control and configure the replication process. By specifying a minimum of one DB instance in the secondary Region, you can ensure that your secondary database is always available and up-to-date, allowing for quick failover in the event of a disaster.
Comment: Actually I change my answer to 'D' because of following: An Aurora DB cluster can contain up to 15 Aurora Replicas. The Aurora Replicas can be distributed across the Availability Zones that a DB cluster spans WITHIN an AWS Region. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.htmhttps://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html You can replicate data across multiple Regions by using an Aurora global database
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html Global database is for specific versions - they did not tell us the version https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
Comment: Parameter Store does not provide automatic credential rotation.
Comment: C. Create credentials on the RDS for MySQL database for the application user and store the credentials in AWS Secrets Manager. Configure the application to load the database credentials from Secrets Manager. Set up a credentials rotation schedule for the application user in the RDS for MySQL database using Secrets Manager. https://www.examtopics.com/discussions/amazon/view/46483-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: credentials from Secrets Manager...
Comment: question is asking for "more secure with the least amount of programming effort." = Secrets Manager + Secretes Manager's built in rotation schedule instead of Lambda.
Comment: A KMS is for encryption keys specifically so this is a long way of doing the credentials storage B is too much work for rotation C exactly what secrets manager is designed for D You can do that if C wasn't an option
Comment: Store the RDS credentials in Secrets Manager Configure the application to retrieve the credentials from Secrets Manager Use Secrets Manager's built-in rotation to rotate the RDS credentials automatically
Comment: Secrets Manager can handle the rotation, so no need for Lambda to rotate the keys.
Comment: WHY NOT B ?
Comment: B, we need lambda for password rotation, confirmed!
Comment: It is not needed for certain types RDS, including MySQL as Secrets Manager has built-in rotation capabilities for it: https://aws.amazon.com/blogs/security/rotate-amazon-rds-database-credentials-automatically-with-aws-secrets-manager/
Comment: If you need your DB to store credentials then use AWS Secret Manager. System Manager Paramater Store is for CloudFormation (no rotation)
Comment: why it's not A?
Comment: It is asking for credentials, not for encryption keys.
Comment: So credentials rotation is secrets manager and key rotation is KMS?
Comment: https://aws.amazon.com/blogs/security/rotate-amazon-rds-database-credentials-automatically-with-aws-secrets-manager/
Comment: C is a valid solution for securing the custom application with the least amount of programming effort. It involves creating credentials on the RDS for MySQL database for the application user and storing them in AWS Secrets Manager. The application can then be configured to load the database credentials from Secrets Manager. Additionally, the solution includes setting up a credentials rotation schedule for the application user in the RDS for MySQL database using Secrets Manager, which will automatically rotate the credentials at a specified interval without requiring any programming effort.
Comment: https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_database_secret.html
Comment: Answer - C https://ws.amazon.com/blogs/security/rotate-amazon-rds-database-credentials-automatically-with-aws-secrets-manager/
Comment: A. Use AWS WAF in front of the ALB. Associate the appropriate web ACLs with AWS WAF. SQL Injection - AWS WAF DDoS - AWS Shield
Comment: Answer - A https://aws.amazon.com/premiumsupport/knowledge-center/waf-block-common-attacks/#:~:text=To%20protect%20your%20applications%20against,%2C%20query%20string%2C%20or%20URI. ----------------------------------------------------------------------------------------------------------------------- Protect against SQL injection and cross-site scripting To protect your applications against SQL injection and cross-site scripting (XSS) attacks, use the built-in SQL injection and cross-site scripting engines. Remember that attacks can be performed on different parts of the HTTP request, such as the HTTP header, query string, or URI. Configure the AWS WAF rules to inspect different parts of the HTTP request against the built-in mitigation engines.
Comment: AWS WAF - for SQL Injection ---> A AWS Shield - for DDOS Amazon Inspector - for automated security assessment, like known vulnerability
Comment: ° Use AWS WAF in front of the Application Load Balancer ° Configure appropriate WAF web ACLs to detect and block SQL injection patterns The key points: ° Website hosted on EC2 behind an ALB with Aurora database ° Application is vulnerable to SQL injection attacks ° AWS WAF is designed to detect and block SQL injection and other common web exploits. It can be placed in front of the ALB to inspect all incoming requests. WAF rules can identify malicious SQL patterns and block them.
Comment: SQL injection -> WAF
Comment: WAF is the right one
Comment: SQL Injection - AWS WAF DDoS - AWS Shield
Comment: Answer C - Shield Advanced (WAF + Firewall Manager)
Comment: It is A. I am happy to see Amazon gives out score like this...
Comment: AWS WAF is a managed service that protects web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF enables customers to create custom rules that block common attack patterns, such as SQL injection attacks. By using AWS WAF in front of the ALB and associating the appropriate web ACLs with AWS WAF, the company can protect its website application from SQL injection attacks. AWS WAF will inspect incoming traffic to the website application and block requests that match the defined SQL injection patterns in the web ACLs. This will help to prevent SQL injection attacks from reaching the application, thereby improving the overall security posture of the application.
Comment: B, C, and D are not the best solutions for this issue. Replying to SQL injections with a fixed response (B) is not a recommended approach as it does not actually fix the vulnerability, but only masks the issue. Subscribing to AWS Shield Advanced (C) is useful to protect against DDoS attacks but does not protect against SQL injection vulnerabilities. Amazon Inspector (D) is a vulnerability assessment tool and can identify vulnerabilities but cannot block attacks in real-time.
Comment: Bhawesh answers it perfect so I'm avoiding redundancy but agree on it being A.
Comment: This solution leverages AWS Lake Formation to ingest data from the Aurora MySQL database into the S3 data lake, while enforcing column-level access control for QuickSight users. Lake Formation can be used to create and manage the data lake's metadata and enforce security and governance policies, including column-level access control. This solution then uses Amazon Athena as the data source in QuickSight to query the data in the S3 data lake. This solution minimizes operational overhead by leveraging AWS services to manage and secure the data, and by using a standard query service (Amazon Athena) to provide a SQL interface to the data.
Comment: Answer - D https://aws.amazon.com/blogs/big-data/enforce-column-level-authorization-with-amazon-quicksight-and-aws-lake-formation/
Comment: https://docs.aws.amazon.com/lake-formation/latest/dg/workflows-about.html
Comment: Use a Lake Formation blueprint to ingest data from the Aurora database into the S3 data lake Leverage Lake Formation to enforce column-level access control for the marketing team Use Amazon Athena as the data source in QuickSight The key points: Need to join S3 data lake data with Aurora MySQL data Require column-level access controls for marketing team in QuickSight Minimize operational overhead
Comment: Using a Lake Formation blueprint to ingest the data from the database to the S3 data lake, using Lake Formation to enforce column-level access control for the QuickSight users, and using Amazon Athena as the data source in QuickSight. This solution requires the least operational overhead as it utilizes the features provided by AWS Lake Formation to enforce column-level authorization, which simplifies the process and reduces the need for additional configuration and maintenance.
Comment: D. Use a Lake Formation blueprint to ingest the data from the database to the S3 data lake. Use Lake Formation to enforce column-level access control for the QuickSight users. Use Amazon Athena as the data source in QuickSight. https://www.examtopics.com/discussions/amazon/view/80865-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: B is NOT correct. the question said "The company does not have the resources to analyze the required capacity trends for the Auto Scaling group counts.". answer B said "Set the appropriate desired capacity, minimum capacity, and maximum capacity". how can someone set desired capacity if he has no resources to analyze the required capacity. Read carefully Amigo
Comment: scheduled scaling....
Comment: works loads can vary, how can you predict something that is random?
Comment: But you can make a vague estimation according to the resources used; you don't need to make machine learning models to do that. You only need common sense.
Comment: Your explanation is contradicting your answer. Since "the company does not have the resources to analyze the required capacity trend for the ASG", how come they can create and ASG based on a historic trend? C doesn't make sense for me.
Comment: A scheduled scaling policy allows you to set up specific times for your Auto Scaling group to scale out or scale in. By creating a scheduled scaling policy for the Auto Scaling group, you can set the appropriate desired capacity, minimum capacity, and maximum capacity, and set the recurrence to weekly. You can then set the start time to 30 minutes before the batch jobs run, ensuring that the required capacity is provisioned before the jobs run. Option C, creating a predictive scaling policy for the Auto Scaling group, is not necessary in this scenario since the company does not have the resources to analyze the required capacity trends for the Auto Scaling group counts. This would require analyzing the required capacity trends for the Auto Scaling group counts to determine the appropriate scaling policy.
Comment: (typo above) C is correct..
Comment: Look at fkie4 comment... no way to know desired capacity!!! -> B not correct
Comment: the text says 1.-"A transaction processing company has weekly scripted batch jobs", there is a Schedule 2.-" The company does not have the resources to analyze the required capacity trends for the Auto Scaling " Do not use the answer is B
Comment: B is correct. "Predictive scaling uses machine learning to predict capacity requirements based on historical data from CloudWatch.", meaning the company does not have to analyze the capacity trends themselves. https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html
Comment: B or C. I think C because the company needs an automated way to modify the autoscaling desired capacity
Comment: How does C works with : transactions can vary, clearly C is designed for workloads that are predictable, if the transactions can vary then predictive scaling will not work. The only one that will work is scheduled since its based on time not workload intensity.
Comment: C per https://docs.aws.amazon.com/autoscaling/ec2/userguide/predictive-scaling-create-policy.html. B is out because it wants the company to 'set the desired/minimum/maximum capacity' but "the company does not have the resources to analyze the required capacity".
Comment: Lambda did not appear to take over scripting/batch job, what a surprise
Comment: From GPT4: mong the provided options, creating a scheduled scaling policy (Option B) is the most direct and efficient way to ensure that the necessary capacity is provisioned 30 minutes before the weekly batch jobs run, with the least operational overhead. Here's a breakdown of Option B: B. Create a scheduled scaling policy for the Auto Scaling group. Set the appropriate desired capacity, minimum capacity, and maximum capacity. Set the recurrence to weekly. Set the start time to 30 minutes before the batch jobs run. Scheduled scaling allows you to change the desired capacity of your Auto Scaling group based on a schedule. In this case, setting the recurrence to weekly and adjusting the start time to 30 minutes before the batch jobs run will ensure that the necessary capacity is available when needed, without requiring manual intervention.
Comment: yeah chatgpt told me this, so maybe dont take its word as gospel: Upon reviewing the question again, it appears that the requirements emphasize the need to provision capacity 30 minutes before the batch jobs run and the company's constraint of not having resources to analyze capacity trends. In this context, the most suitable solution is C. Predictive Scaling can use historical data to forecast future capacity needs. Configuring the policy to scale based on CPU utilization with a target value of 60% aligns with the baseline CPU utilization mentioned in the scenario. Setting instances to pre-launch 30 minutes before the jobs run provides the desired capacity just in time.
Comment: Predictive scaling: increases the number of EC2 instances in your Auto Scaling group in advance of daily and weekly patterns in traffic flows. If you have regular patterns of traffic increases use predictive scaling, to help you scale faster by launching capacity in advance of forecasted load. You don't have to spend time reviewing your application's load patterns and trying to schedule the right amount of capacity using scheduled scaling. Predictive scaling uses machine learning to predict capacity requirements based on historical data from CloudWatch. The machine learning algorithm consumes the available historical data and calculates capacity that best fits the historical load pattern, and then continuously learns based on new data to make future forecasts more accurate.
Comment: should be C. Question does not say how long the job will run. don't know when to set the end time in the schedule policy.
Comment: C is correct!
Comment: if the baseline CPU utilization is 60%, then that's enough information needed to determaine you to predict some aspect of the usage in the future. So key word "predictive" judging by past usage.
Comment: BBBBBBBBBBBBB
Comment: B. you can make a vague estimation according to the resources used; you don't need to make machine-learning models to do that. You only need common sense.
Comment: Use predictive scaling to increase the number of EC2 instances in your Auto Scaling group in advance of daily and weekly patterns in traffic flows. Predictive scaling is well suited for situations where you have: Cyclical traffic, such as high use of resources during regular business hours and low use of resources during evenings and weekends Recurring on-and-off workload patterns, such as batch processing, testing, or periodic data analysis Applications that take a long time to initialize, causing a noticeable latency impact on application performance during scale-out events https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html
Comment: The second part of the question invalidates option B, they don't know how to procure requirements and need something to do it for them, therefore C.
Comment: In general, if you have regular patterns of traffic increases and applications that take a long time to initialize, you should consider using predictive scaling. Predictive scaling can help you scale faster by launching capacity in advance of forecasted load, compared to using only dynamic scaling, which is reactive in nature.
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html
Comment: A. Multiple EC2 instances to be configured and updated manually in case of DR. B. Amazon RDS=Multi-AZ while it asks to be multi-region C. correct, see comment from LuckyAro D. Manual process to start the DR, therefore same limitation as answer A
Comment: C: Migrate MySQL database to an Amazon Aurora global database is the best solution because it requires minimal operational overhead. Aurora is a managed service that provides automatic failover, so standby instances do not need to be manually configured. The primary DB cluster can be hosted in the primary Region, and the secondary DB cluster can be hosted in the DR Region. This approach ensures that the data is always available and up-to-date in multiple Regions, without requiring significant manual intervention.
Comment: hello friends, question required: The DR design needs to include multiple AWS Regions, but the correct answer is B, how it comes, because the DR here is on AZ not Different Region so the i would go with D
Comment: LEAST operational overhead = Serverless = Amazon Aurora global database
Comment: Amazon Aurora global database can span and replicate DB Servers between multiple AWS Regions. And also compatible with MySQL.
Comment: C, Why B? B is multi zone in one region, C is multi region as it was requested
Comment: " The DR design needs to include multiple AWS Regions." with the requirement "DR SITE multiple AWS region" -> B is wrong, because it deploy multy AZ (this is not multi region)
Comment: Amazon Aurora global database can span and replicate DB Servers between multiple AWS Regions. And also compatible with MySQL.
Comment: With dynamic scaling, the Auto Scaling group will automatically adjust the number of instances based on the actual workload. The target value for the CPU utilization metric is set to 60%, which is the baseline CPU utilization that is noted on each run, indicating that this is a reasonable level of utilization for the workload. This solution does not require any scheduling or forecasting, reducing the operational overhead.
Comment: Sorry, Posted right answer to the wrong question, mistakenly clicked the next question, sorry.
Comment: C is the answer as RDS is only multi-zone not multi region.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html
Comment: C option A has operation overhead whereas option C not.
Comment: C mentions multiple regions. Option B is within the same region
Comment: ANSWER - B ?? NOT SURE
Comment: A. Use the Amazon SQS Extended Client Library for Java to host messages that are larger than 256 KB in Amazon S3. Amazon SQS has a limit of 256 KB for the size of messages. To handle messages larger than 256 KB, the Amazon SQS Extended Client Library for Java can be used. This library allows messages larger than 256 KB to be stored in Amazon S3 and provides a way to retrieve and process them. Using this solution, the application code can remain largely unchanged while still being able to process messages up to 50 MB in size.
Comment: A For messages > 256 KB, use Amazon SQS Extended Client Library for Java https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html
Comment: who would know this...
Comment: To send messages larger than 256 KiB, you can use the Amazon SQS Extended Client Library for Java...
Comment: The Amazon SQS Extended Client Library for Java enables you to manage Amazon SQS message payloads with Amazon S3. This is especially useful for storing and retrieving messages with a message payload size greater than the current SQS limit of 256 KB, up to a maximum of 2 GB.
Comment: The SQS Extended Client Library enables storing large payloads in S3 while referenced via SQS. The application code can stay almost entirely unchanged - it sends/receives SQS messages normally. The library handles transparently routing the large payloads to S3 behind the scenes
Comment: Quote "The Amazon SQS Extended Client Library for Java enables you to manage Amazon SQS message payloads with Amazon S3." and "An extension to the Amazon SQS client that enables sending and receiving messages up to 2GB via Amazon S3." at https://github.com/awslabs/amazon-sqs-java-extended-client-lib
Comment: Amazon SQS has a limit of 256 KB for the size of messages. To handle messages larger than 256 KB, the Amazon SQS Extended Client Library for Java can be used.
Comment: The Amazon SQS Extended Client Library for Java enables you to publish messages that are greater than the current SQS limit of 256 KB, up to a maximum of 2 GB. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-s3-messages.html
Comment: https://github.com/awslabs/amazon-sqs-java-extended-client-lib
Comment: To send messages larger than 256 KiB, you can use the Amazon SQS Extended Client Library for Java. This library allows you to send an Amazon SQS message that contains a reference to a message payload in Amazon S3. The maximum payload size is 2 GB.
Comment: CloudFront=globally Lambda@edge = Authorization/ Latency Cognito=Authentication for Web apps
Comment: https://aws.amazon.com/blogs/networking-and-content-delivery/external-server-authorization-with-lambdaedge/
Comment: fewer than 100 users but scattered around the globe, lowest latency. Should have do nothing, most cost effective.
Comment: Use Amazon Cognito for authentication. Use Lambda@Edge for authorization. Use Amazon CloudFront to serve the web application globally
Comment: Amazon Cognito is a serverless authentication service that can be used to easily add user sign-up and authentication to web and mobile apps. It is a good choice for this scenario because it is scalable and can handle a small number of users without any additional costs. Lambda@Edge is a serverless compute service that can be used to run code at the edge of the AWS network. It is a good choice for this scenario because it can be used to perform authorization checks at the edge, which can improve the login latency. Amazon CloudFront is a content delivery network (CDN) that can be used to serve web content globally. It is a good choice for this scenario because it can cache web content closer to users, which can improve the performance of the web application.
Comment: A is perfect.
Comment: Lambda@Edge for authorization https://aws.amazon.com/blogs/networking-and-content-delivery/adding-http-security-headers-using-lambdaedge-and-amazon-cloudfront/
Comment: Amazon CloudFront is a global content delivery network (CDN) service that can securely deliver web content, videos, and APIs at scale. It integrates with Cognito for authentication and with Lambda@Edge for authorization, making it an ideal choice for serving web content globally. Lambda@Edge is a service that lets you run AWS Lambda functions globally closer to users, providing lower latency and faster response times. It can also handle authorization logic at the edge to secure content in CloudFront. For this scenario, Lambda@Edge can provide authorization for the web application while leveraging the low-latency benefit of running at the edge.
Comment: CloudFront to serve globally
Comment: A Amazon Cognito for authentication and Lambda@Edge for authorizatioN, Amazon CloudFront to serve the web application globally provides low-latency content delivery
Comment: Amazon S3 File Gateway provides on-premises applications with access to virtually unlimited cloud storage using NFS and SMB file interfaces. It seamlessly moves frequently accessed data to a low-latency cache while storing colder data in Amazon S3, using S3 Lifecycle policies to transition data between storage classes over time. In this case, the company's aging NAS array can be replaced with an Amazon S3 File Gateway that presents the same NFS and SMB shares to the client workstations. The data can then be migrated to Amazon S3 and managed using S3 Lifecycle policies
Comment: Amazon S3 File Gateway provides a file interface to objects stored in S3. It can be used for a file-based interface with S3, which allows the company to migrate their NAS array data to S3 while maintaining the same look and feel for client workstations. Amazon S3 File Gateway supports SMB and NFS protocols, which will allow clients to continue to access the data using these protocols. Additionally, Amazon S3 Lifecycle policies can be used to automate the movement of data to lower-cost storage tiers, reducing the storage cost of inactive data.
Comment: A - provides virtual disk via iSCSI B - provides virtual tape via iSCSI C - provides access to FSx via SMB
Comment: The Amazon S3 File Gateway enables you to store and retrieve objects in Amazon Simple Storage Service (S3) using file protocols such as Network File System (NFS) and Server Message Block (SMB).
Comment: It provides an easy way to lift-and-shift file data from the existing NAS to Amazon S3. The S3 File Gateway presents SMB and NFS file shares that client workstations can access just like the NAS shares. Behind the scenes, it moves the file data to S3 storage, storing it durably and cost-effectively. S3 Lifecycle policies can be used to transition less frequently accessed data to lower-cost S3 storage tiers like S3 Glacier. From the client workstation perspective, access to files feels seamless and unchanged after migration to S3. The S3 File Gateway handles the underlying data transfers. It is a simple, low-cost gateway option tailored for basic file share migration use cases.
Comment: - Volume Gateway: https://aws.amazon.com/storagegateway/volume/ (Remove A, related iSCSI) - Tape Gateway https://aws.amazon.com/storagegateway/vtl/ (Remove B) - Amazon FSx File Gateway https://aws.amazon.com/storagegateway/file/fsx/ (C) - Why not choose C? Because need working with Amazon S3. (Answer D, and it is correct answer) https://aws.amazon.com/storagegateway/file/s3/
Comment: https://aws.amazon.com/blogs/storage/how-to-create-smb-file-shares-with-aws-storage-gateway-using-hyper-v/
Comment: https://aws.amazon.com/about-aws/whats-new/2018/06/aws-storage-gateway-adds-smb-support-to-store-objects-in-amazon-s3/
Comment: Read Carefully guys , They need to be able to change FAMILY , and although EC2 Savings has a higher discount , its clearly documented as not allowed > EC2 Instance Savings Plans provide savings up to 72 percent off On-Demand, in exchange for a commitment to a specific instance family in a chosen AWS Region (for example, M5 in Virginia). These plans automatically apply to usage regardless of size (for example, m5.xlarge, m5.2xlarge, etc.), OS (for example, Windows, Linux, etc.), and tenancy (Host, Dedicated, Default) within the specified family in a Region.
Comment: Savings Plans are a flexible pricing model that offer low prices on Amazon EC2, AWS Lambda, and AWS Fargate usage, in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3 year term. When you sign up for a Savings Plan, you will be charged the discounted Savings Plans price for your usage up to your commitment. The company wants savings over the next 3 years but wants to change the instance type in 6 months. This invalidates A
Comment: Disregard! found more information: We recommend Savings Plans (over Reserved Instances). Like Reserved Instances, Savings Plans offer lower prices (up to 72% savings compared to On-Demand Instance pricing). In addition, Savings Plans offer you the flexibility to change your usage as your needs evolve. For example, with Compute Savings Plans, lower prices will automatically apply when you change from C4 to C6g instances, shift a workload from EU (Ireland) to EU (London), or move a workload from Amazon EC2 to AWS Fargate or AWS Lambda. https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/
Comment: https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/savings-plans.html Compute Savings Plans provide the most flexibility and help to reduce your costs by up to 66% (just like Convertible RIs). These plans automatically apply to EC2 instance usage regardless of instance family... EC2 Instance Savings Plans provide the lowest prices, offering savings up to 72% (just like Standard RIs) in exchange for commitment to usage of individual instance families Instance Savings "locks" you in that instance family which is not desired by the company hence A is the best plan as they can change the instance family anytime
Comment: Also, don't forget, the minimum commitment for both of these plans is 1 year and the company wants the ability to change in 6 months so it has to be a plan which allows changing of instance within the commitment window (no refunds!)
Comment: EC2 Instance Savings Plans provide the lowest prices, offering savings up to 72% in exchange for commitment to usage of individual instance families in a region (e.g. M5 usage in N. Virginia). This automatically reduces your cost on the selected instance family in that region regardless of AZ, size, OS or tenancy. ***EC2 Instance Savings Plans give you the flexibility to change your usage between instances within a family in that region.*** For example, you can move from c5.xlarge running Windows to c5.2xlarge running Linux and automatically benefit from the Savings Plans prices. https://aws.amazon.com/savingsplans/faq/#:~:text=EC2%20Instance%20Savings%20Plans%20give,from%20the%20Savings%20Plans%20prices.
Comment: B is the definite answer
Comment: B does not allow changing the instance family, despite all the ChatGPT-based answers claiming the opposite
Comment: While EC2 Instance Savings Plans also provide cost savings over On-Demand pricing, they offer less flexibility in terms of changing instance families. They provide a discount in excha
Comment: EC2 Instance Savings Plans is most saving. And it is enough for required flexibility EC2 Instance Savings Plans provide the lowest prices, offering savings up to 72% (just like Standard RIs) in exchange for commitment to usage of individual instance families in a Region (for example, M5 usage in N. Virginia). This automatically reduces your cost on the selected instance family in that region regardless of AZ, size, operating system, or tenancy. EC2 Instance Savings Plans give you the flexibility to change your usage between instances within a family in that Region. For example, you can move from c5.xlarge running Windows to c5.2xlarge running Linux and automatically benefit from the Savings Plans prices.
Comment: You voted against yourself. Did you mean to vote A?
Comment: But it does not allow changing the instance family, which is a requirement here.
Comment: https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/savings-plans.html
Comment: The most cost-effective solution that meets the company's requirements would be B. EC2 Instance Savings Plan. EC2 Instance Savings Plans provide significant cost savings, allowing the company to commit to a consistent amount of usage (measured in $/hour) for a 1- or 3-year term, and in return, receive a discount on the hourly rate for the instances that match the attributes of the plan. With EC2 Instance Savings Plans, the company can benefit from the flexibility to change the instance family and sizes over the next 3 years, which aligns with their requirement to adjust based on application popularity and usage. This option provides the best balance of cost savings and flexibility, making it the most suitable choice for the company's needs.
Comment: "With EC2 Instance Savings Plans, the company can benefit from the flexibility to change the instance family" NO, this is simply wrong. Is this from ChatGPT? "EC2 Instance Savings Plans provide savings up to 72 percent off On-Demand, in exchange for a commitment to a specific instance family (!) in a chosen AWS Region ... With an EC2 Instance Savings Plan, you can change your instance size within the instance family (!)". https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
Comment: Change instance family = Compute Savings Plans
Comment: D is not right. D. Standard Reserved Instances. should be Convertible Reserved Instances if you need additional flexibility, such as the ability to use different instance families, operating systems.
Comment: The key factors are: Need to maximize cost savings over 3 years Ability to change instance family and sizes in 6 months Standardized on a particular instance family for now
Comment: "Ability to change instance family and sizes in 6 months" is not allowed in Instance Savings plan so B is wrong
Comment: Why not C? Can do with Convertible Reserved Instance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-types.html
Comment: https://aws.amazon.com/savingsplans/compute-pricing/
Comment: EC2 Instance Savings Plan cannot change the family. https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
Comment: Anser D: You can use Standard Reserved Instances when you know that you need a specific instance type.
Comment: Savings Plans offer a flexible pricing model that provides savings on AWS usage. You can save up to 72 percent on your AWS compute workloads. Compute Savings Plans provide lower prices on Amazon EC2 instance usage regardless of instance family, size, OS, tenancy, or AWS Region. This also applies to AWS Fargate and AWS Lambda usage. SageMaker Savings Plans provide you with lower prices for your Amazon SageMaker instance usage, regardless of your instance family, size, component, or AWS Region. https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
Comment: With an EC2 Instance Savings Plan, you can change your instance size within the instance family (for example, from c5.xlarge to c5.2xlarge) or the operating system (for example, from Windows to Linux), or move from Dedicated tenancy to Default and continue to receive the discounted rate provided by your EC2 Instance Savings Plan. https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
Comment: The company needs to be able to change the instance family and sizes in the next 6 months based on application popularity and usage. Therefore EC2 Instance Savings Plan prerequisites are not fulfilled
Comment: The data workload is constant and predictable.
Comment: I think it is not possible to set Read Capacity Units(RCU)/Write Capacity Units(WCU) in on-demand mode.
Comment: C and D are impossible because you don't set or specify RCUs and WCUs in on-demand mode. A is wrong because there is no indication of "infrequent access", and "the data workload is constant", there is no different between the current and the "forecasted" workload.
Comment: predictable/constant => provisioned mode. On-demand mode is more suitable for workloads that are unpredictable and can vary widely from minute to minute. The use case is not for Standard-IA which is described here: https://aws.amazon.com/dynamodb/standard-ia/ => Option B
Comment: I rule out A because of this 'Standard-Infrequent Access ', clearly the company uses applications to analyze the data. The data workload is constant and predictable making provisioned mode the best option.
Comment: Option B lacks the cost benefits of Standard-IA. Option C uses more expensive on-demand pricing. Option D does not actually allow reserving capacity with on-demand mode. So option A leverages provisioned mode, Standard-IA, and reserved capacity to meet the requirements in a cost-optimal way.
Comment: A is correct!
Comment: Sorry, A will not work, since Reserved Capacity can only be used with DynamoDB Standard table class. So, B is right for this case.
Comment: 예측가능..
Comment: Option C is the most cost-effective solution for this scenario. In on-demand mode, DynamoDB automatically scales up or down based on the current workload, so the company only pays for the capacity it uses. By setting the RCUs and WCUs high enough to accommodate changes in the workload, the company can ensure that it always has the necessary capacity without overprovisioning and incurring unnecessary costs. Since the workload is constant and predictable, using provisioned mode with reserved capacity (Options A and D) may result in paying for unused capacity during periods of low demand. Option B, using provisioned mode without reserved capacity, may result in throttling during periods of high demand if the provisioned capacity is not sufficient to handle the workload.
Comment: Kayode olode..lol
Comment: you forgot "The data workload is constant and predictable", should be B
Comment: You can't 'set RCUs and WCUs' in on-demand mode.
Comment: "The data workload is constant and predictable." https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html "With provisioned capacity you pay for the provision of read and write capacity units for your DynamoDB tables. Whereas with DynamoDB on-demand you pay per request for the data reads and writes that your application performs on your tables."
Comment: The data workload is constant and predictable, then, isn't on-demand mode. DynamoDB Standard-IA is not necessary in this context
Comment: The problem with (A) is: “Standard-Infrequent Access“. In the question, they say the company has to analyze the Data. That's why the Correct answer is (B)
Comment: workload is constant
Comment: The problem with (A) is: “Standard-Infrequent Access“. In the question, they say the company has to analyze the Data. Correct answer is (B)
Comment: As the numbers are already known
Comment: A. - "So let me get this straight, with the current company the data is protected and encrypted. However, for the acquiring company the data is unencrypted? How is that fair?" C - Wouldn't recommended this option because using a different AWS managed KMS key will not allow the acquiring company's AWS account to access the encrypted data. D. - Don't risk it for a biscuit and get fired!!!! - by downloading the database snapshot and uploading it to an Amazon S3 bucket. This will increase the risk of data leakage or loss of confidentiality during the transfer process. B - CORRECT
Comment: I believe the reason why option C is not the correct answer is that adding the acquiring company's AWS account to the KMS key alias doesn't directly control access to the encrypted data. KMS key aliases are simply alternative names for KMS keys and do not affect access control. Access to encrypted data is goverened by KMS key policies, which define who can use the key for encryption and decryption.
Comment: Create a database snapshot. Add the acquiring company's AWS account to the KMS key policy. Share the snapshot with the acquiring company's AWS account.
Comment: B. Create a database snapshot. Add the acquiring company's AWS account to the KMS key policy. Share the snapshot with the acquiring company's AWS account. Most Voted
Comment: Create a database snapshot of the encrypted. Add the acquiring company's AWS account to the KMS key policy. Share the snapshot with the acquiring company's AWS account.
Comment: To securely share a backup of the database with the acquiring company's AWS account in the same Region, a solutions architect should create a database snapshot, add the acquiring company's AWS account to the AWS KMS key policy, and share the snapshot with the acquiring company's AWS account. Option A, creating an unencrypted snapshot, is not recommended as it will compromise the confidentiality of the data. Option C, creating a snapshot that uses a different AWS managed KMS key, does not provide any additional security and will unnecessarily complicate the solution. Option D, downloading the database snapshot and uploading it to an S3 bucket, is not secure as it can expose the data during transit. Therefore, the correct option is B: Create a database snapshot. Add the acquiring company's AWS account to the KMS key policy. Share the snapshot with the acquiring company's AWS account.
Comment: Option B is the correct answer. Option A is not recommended because copying the snapshot to a new unencrypted snapshot will compromise the confidentiality of the data. Option C is not recommended because using a different AWS managed KMS key will not allow the acquiring company's AWS account to access the encrypted data. Option D is not recommended because downloading the database snapshot and uploading it to an Amazon S3 bucket will increase the risk of data leakage or loss of confidentiality during the transfer process.
Comment: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
Comment: It is C, you have to create a new key. Read below You can't share a snapshot that's encrypted with the default AWS KMS key. You must create a custom AWS KMS key instead. To share an encrypted Aurora DB cluster snapshot: Create a custom AWS KMS key. Add the target account to the custom AWS KMS key. Create a copy of the DB cluster snapshot using the custom AWS KMS key. Then, share the newly copied snapshot with the target account. Copy the shared DB cluster snapshot from the target account https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/
Comment: I also thought straight away that it could be C, however, the questions mentions that the database is encrypted with an AWS KMS custom key already. So maybe the letter B could be right, since it already has a custom key, not the default KMS Key. What do you think?
Comment: It is B. There's no need to create another custom AWS KMS key. https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/ Give target account access to the custom AWS KMS key within the source account 1. Log in to the source account, and go to the AWS KMS console in the same Region as the DB cluster snapshot. 2. Select Customer-managed keys from the navigation pane. 3. Select your custom AWS KMS key (ALREADY CREATED) 4. From the Other AWS accounts section, select Add another AWS account, and then enter the AWS account number of your target account. Then: Copy and share the DB cluster snapshot
Comment: Yes, as per the given information "The database is encrypted with an AWS Key Management Service (AWS KMS) customer managed key", it may not be the default AWS KMS key.
Comment: Yes, can't share a snapshot that's encrypted with the default AWS KMS key. But as per the given information "The database is encrypted with an AWS Key Management Service (AWS KMS) customer managed key", it may not be the default AWS KMS key.
Comment: I agree with KZM. It is B. There's no need to create another custom AWS KMS key. https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/ Give target account access to the custom AWS KMS key within the source account 1. Log in to the source account, and go to the AWS KMS console in the same Region as the DB cluster snapshot. 2. Select Customer-managed keys from the navigation pane. 3. Select your custom AWS KMS key (ALREADY CREATED) 4. From the Other AWS accounts section, select Add another AWS account, and then enter the AWS account number of your target account. Then: Copy and share the DB cluster snapshot
Comment: Is it bad that in answer B the acquiring company is using the same KMS key? Should a new KMS key not be used?
Comment: Yes, you are right, read my comment above.
Comment: I think I would agree with you if option C say using a new "customer managed key" instead of AWS managed key
Comment: https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/
Comment: ANSWER - B
Comment: A and C are the correct choices. B. It will not help improve the performance of the report process. D. Migrating to RDS Custom does not address the issue of high availability and automatic recovery. E. RDS Proxy can help with scalability and high availability but it does not address the issue of performance for the report process. Limiting the reporting requests to the maintenance window will not provide the required availability and recovery for the DB instance.
Comment: Create a Multi-AZ deployment, create a read replica of the DB instance in the second Availability Zone, point all requests for reports to the read replica
Comment: The correct answers are A and C. A. Modify the DB instance from a Single-AZ DB instance to a Multi-AZ deployment. This will provide high availability and automatic recovery for the DB instance. If the primary DB instance fails, the standby DB instance will automatically become the primary DB instance. This will ensure that the database is always available. C. Create a read replica of the DB instance in a different Availability Zone. Point all requests for reports to the read replica. This will improve the performance of the report process by offloading the read traffic from the primary DB instance to the read replica. The read replica is a fully synchronized copy of the primary DB instance, so the reports will be accurate.
Comment: A and C.
Comment: Options A & C...
Comment: Options A+C
Comment: https://medium.com/awesome-cloud/aws-difference-between-multi-az-and-read-replicas-in-amazon-rds-60fe848ef53a
Comment: ANSWER - A & C
Comment: This is why I'm voting D…..QUESTION ASKED FOR IT TO: use serverless concepts while performing the different aspects of the workflow. Is option D utilizing Serverless concepts?
Comment: It is D. Cannot be C because C is "scheduled"
Comment: While considering this requirement: The architecture needs to be more distributed and to use serverless concepts while performing the different aspects of the workflow And checking the following link : https://aws.amazon.com/step-functions/?nc1=h_ls, Answer D is the best for this use case
Comment: One of the use cases for step functions is to Automate extract, transform, and load (ETL) processes. https://aws.amazon.com/step-functions/#:~:text=for%20modern%20applications.-,Use%20cases,-Automate%20extract%2C%20transform
Comment: AWS Step functions is serverless Visual workflows for distributed applications https://aws.amazon.com/step-functions/
Comment: Step Functions is based on state machines and tasks. A state machine is a workflow. A task is a state in a workflow that represents a single unit of work that another AWS service performs. Each step in a workflow is a state. Depending on your use case, you can have Step Functions call AWS services, such as Lambda, to perform tasks. https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
Comment: Answer is D. Step Functions is based on state machines and tasks. A state machine is a workflow. A task is a state in a workflow that represents a single unit of work that another AWS service performs. Each step in a workflow is a state. Depending on your use case, you can have Step Functions call AWS services, such as Lambda, to perform tasks. https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
Comment: There are two main types of routers used in event-driven architectures: event buses and event topics. At AWS, we offer Amazon EventBridge to build event buses and Amazon Simple Notification Service (SNS) to build event topics. https://aws.amazon.com/event-driven-architecture/
Comment: How do you 'build out a workflow' in EventBridge?
Comment: Step 3: Create a State Machine Use the Step Functions console to create a state machine that invokes the Lambda function that you created earlier in Step 1. https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-creating-lambda-state-machine.html In Step Functions, a workflow is called a state machine, which is a series of event-driven steps. Each step in a workflow is called a state.
Comment: Distrubuted****
Comment: Vou de C, orientada a eventos
Comment: It is true that an Event-driven is made with EventBridge but with a Lambda on schedule??? It is a mismatch, isn´t it?
Comment: Tricky question huh!
Comment: AWS Step functions is serverless Visual workflows for distributed applications https://aws.amazon.com/step-functions/
Comment: Besides, "Visualize and develop resilient workflows for EVENT-DRIVEN architectures."
Comment: Could it be a C because it's event-driven architecture?
Comment: Option D.. AWS Step functions are used for distributed applications
Comment: AWS Global Accelerator = TCP/UDP minimize latency
Comment: online game -> Global Accelerator cloudfront is for static/dynamic content caching
Comment: Set up AWS Global Accelerator with UDP listeners and endpoint groups in each Region.
Comment: Connect to up to 10 regions within the AWS global network using the AWS Global Accelerator.
Comment: UDP = Global Accelerator
Comment: General Q: What is AWS Global Accelerator? A: AWS Global Accelerator is a networking service that helps you improve the availability and performance of the applications that you offer to your global users. AWS Global Accelerator is easy to set up, configure, and manage. It provides static IP addresses that provide a fixed entry point to your applications and eliminate the complexity of managing specific IP addresses for different AWS Regions and Availability Zones. AWS Global Accelerator always routes user traffic to the optimal endpoint based on performance, reacting instantly to changes in application health, your user's location, and policies that you configure. You can test the performance benefits from your location with a speed comparison tool. Like other AWS services, AWS Global Accelerator is a self-service, pay-per-use offering, requiring no long term commitments or minimum fees. https://aws.amazon.com/global-accelerator/faqs/
Comment: Global Accelerator supports the User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), making it an excellent choice for an online multi-player game using UDP networking protocol. By setting up Global Accelerator with UDP listeners and endpoint groups in each Region, the network architecture can minimize latency and packet loss, giving end users a high-quality gaming experience.
Comment: AWS Global Accelerator is a service that improves the availability and performance of applications with local or global users. Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions. Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover. Both services integrate with AWS Shield for DDoS protection.
Comment: Global Accelerator for UDP and TCP traffic
Comment: Global Accelerator
Comment: B Global Accelerator for UDP traffic
Comment: RDS does not support IO2 or IO2express . GP2 can do the required IOPS RDS supported Storage > https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html GP2 max IOPS > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp2-performance
Comment: RDS now supports io2 but it might still be an overkill given Gp2 is enough and we are looking for the most cost effective solution.
Comment: RDS does not support IO2 or IO2express . GP2 can do the required IOPS
Comment: The Options is A only because it is sufficient.. Provisioned IOPS are available but overkill.. just want to make sure we understand why its A for the right reason
Comment: Provisioned IOPS are available, but not io2, just io1.
Comment: Simplified by Almero - thanks. RDS does not support IO2 or IO2express . GP2 can do the required IOPS
Comment: I tried on the portal and only gp3 and i01 are supported. This is 11 May 2023.
Comment: it doesn't matter whether or no io* is supported, using io2 is overkill, you only need 1K IOPS, B is the correct answer
Comment: A Amazon RDS supports the use of Amazon EBS Provisioned IOPS (io2) volumes. When creating a new DB instance or modifying an existing one, you can select the io2 volume type and specify the amount of IOPS and storage capacity required. RDS also supports the newer io2 Block Express volumes, which can deliver even higher performance for mission-critical database workloads.
Comment: Impossible. I just tried on the portal and only io1 and gp3 are supported.
Comment: he most cost-effective solution that meets the requirements is to use a Multi-AZ deployment of an Amazon RDS for MySQL DB instance with a General Purpose SSD (gp2) EBS volume. This solution will provide high availability and fault tolerance while minimizing disruptions and stabilizing performance. The gp2 EBS volume can handle up to 16,000 IOPS. You can also scale up to 64 TiB of storage. Amazon RDS for MySQL provides automated backups, software patching, and automatic host replacement. It also provides Multi-AZ deployments that automatically replicate data to a standby instance in another Availability Zone. This ensures that data is always available even in the event of a failure.
Comment: RDS does not support io2 !!!
Comment: B:gp3 would be the better option, but considering we have only gp2 option and such storage volume - gp2 will be the right choice
Comment: I thought the answer here is A. But when I found the link from Amazon website; as per AWS: Amazon RDS provides three storage types: General Purpose SSD (also known as gp2 and gp3), Provisioned IOPS SSD (also known as io1), and magnetic (also known as standard). They differ in performance characteristics and price, which means that you can tailor your storage performance and cost to the needs of your database workload. You can create MySQL, MariaDB, Oracle, and PostgreSQL RDS DB instances with up to 64 tebibytes (TiB) of storage. You can create SQL Server RDS DB instances with up to 16 TiB of storage. For this amount of storage, use the Provisioned IOPS SSD and General Purpose SSD storage types. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: for DB instances between 1 TiB and 4 TiB, storage is striped across four Amazon EBS volumes providing burst performance of up to 12,000 IOPS. from "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html"
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html Amazon RDS provides three storage types: General Purpose SSD (also known as gp2 and gp3), Provisioned IOPS SSD (also known as io1), and magnetic (also known as standard) B - MOST cost-effectively
Comment: The baseline IOPS performance of gp2 volumes is 3 IOPS per GB, which means that a 1 TB gp2 volume will have a baseline performance of 3,000 IOPS. However, the volume can also burst up to 16,000 IOPS for short periods, but this burst performance is limited and may not be sustained for long durations. So, I am more prefer option A.
Comment: If a 1 TB gp3 EBS volume is used, the maximum available IOPS according to calculations is 3000. This means that the storage can support a requirement of 1000 IOPS, and even 2000 IOPS if the requirement is doubled. I am confusing between choosing A or B.
Comment: Option A is the correct answer. A Multi-AZ deployment provides high availability and fault tolerance by automatically replicating data to a standby instance in a different Availability Zone. This allows for seamless failover in the event of a primary instance failure. Using an io2 Block Express EBS volume provides the needed IOPS performance and capacity for the database. It is also designed for low latency and high durability, which makes it a good choice for a database tier.
Comment: How will you select io2 when RDS only offers io1....magic?
Comment: Correction - hit wrong answer button - meant 'B' Amazon RDS provides three storage types: General Purpose SSD (also known as gp2 and gp3), Provisioned IOPS SSD (also known as io1) https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: Amazon RDS provides three storage types: General Purpose SSD (also known as gp2 and gp3), Provisioned IOPS SSD (also known as io1) https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: Many applications, including those built on modern serverless architectures, can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability. With RDS Proxy, failover times for Aurora and RDS databases are reduced by up to 66%. https://aws.amazon.com/rds/proxy/
Comment: A. Reduce the Lambda concurrency rate? Has nothing to do with decreasing connections timeout. B. Enable RDS Proxy on the RDS DB instance. Correct answer C. Resize the RDS DB instance class to accept more connections? More connections means worse performance. Therefore, not correct. D. Migrate the database to Amazon DynamoDB with on-demand scaling? DynamoDB is a noSQL database. Not correct.
Comment: RDS Proxy is a fully managed, highly available, and scalable proxy for Amazon Relational Database Service (RDS) that makes it easy to connect to your RDS instances from applications running on AWS Lambda. RDS Proxy offloads the management of connections to the database, which can help to improve performance and reliability.
Comment: To reduce application failures resulting from database connection timeouts, the best solution is to enable RDS Proxy on the RDS DB instance
Comment: RDS Proxy
Comment: RDS Proxy will pool connections, no code changes need to be made
Comment: RDS proxy
Comment: B RDS Proxy https://aws.amazon.com/rds/proxy/
Comment: The amount of CPU and memory resources required by the batch job exceeds the capabilities of AWS Lambda and Amazon Lightsail with AWS Auto Scaling, which offer limited compute resources. AWS Fargate offers containerized application orchestration and scalable infrastructure, but may require additional operational overhead to configure and manage the environment. AWS Batch is a fully managed service that automatically provisions the required infrastructure for batch jobs, with options to use different instance types and launch modes. Therefore, the solution that will run the batch job within 15 minutes with the LEAST operational overhead is D. Use AWS Batch on Amazon EC2. AWS Batch can handle all the operational aspects of job scheduling, instance management, and scaling while using Amazon EC2 injavascript:void(0)stances with the right amount of CPU and memory resources to meet the job's requirements.
Comment: AWS Batch is a fully-managed service that can launch and manage the compute resources needed to execute batch jobs. It can scale the compute environment based on the size and timing of the batch jobs.
Comment: The question needs to be phrased differently. I assume at first it was Lambda, because it says 15 minutes in the question which can be done. Yes it also does say CPU intensive however they go on with a full stop and then give you the server specs. It does not say it uses that much of the specs so they need to really rephrase the questions.
Comment: The main reasons are: AWS Batch can easily schedule and run batch jobs on EC2 instances. It can scale up to the required vCPUs and memory to match the on-premises server. Using EC2 provides full control over the instance type to meet the resource needs. No servers or clusters to manage like with ECS/Fargate or Lightsail. AWS Batch handles this automatically. More cost effective and operationally simple compared to Lambda which is not ideal for long running batch jobs.
Comment: On-Prem was avg 15 min, but target state architecture is expected to finish within 15 min
Comment: How? The on-prem server has 64 CPUs and 512 GB RAM, Lambda offers much less. And even on-prem it takes 15 minutes ON AVERAGE, sometimes more.
Comment: Not Lambda, "average 15 minutes" means there are jobs with running more and less than 15 minutes. Lambda max is 15 minutes.
Comment: This is for certain a tough one. I do see that they have thrown a curve ball in making it Lambda Functional scaling, however what we dont know is if this application has many request or one large one.. looks like Lambda can scale and use the same lambda env.. seems intensive tho so will go with D
Comment: AWS Batch
Comment: Not A because: "AWS Lambda now supports up to 10 GB of memory and 6 vCPU cores for Lambda Functions." https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-supports-10gb-memory-6-vcpu-cores-lambda-functions/ vs. "The server has 64 virtual CPU (vCPU) and 512 GiB of memory" in the question.
Comment: A is the answer. Lambda is known that has a limit of 15 minutes. So for as long as it says "within 15 minutes" that should be a clear indication it is Lambda
Comment: Wrong, the job takes "On average 15 minutes" and requires more cpu and ram than lambda can deal with. AWS Batch is correct in this scenario
Comment: read the rest of the question which gives the answer: "Which solution will run the batch job within 15 minutes with the LEAST operational overhead?" Keyword "Within 15 minutes"
Comment: What happens if it EXCEEDS the 15 min AVERAGE? Average = possibly can be more than 15min. The safer bet would be option D: AWS Batch on EC2
Comment: I think what he means is that it takes on average 15 min on prem only
Comment: How are you going to get 64 vCPUS to a Lambda function?
Comment: AWS batch on EC2
Comment: One -zone -infrequent access cannot be the answer because it requires high availability so standard infrequent access should be the answer
Comment: Option B
Comment: high availability, resiliency = multi AZ 75% of the data is rarely accessed but remain immediately accessible = Standard-Infrequent Access
Comment: The correct answer is B. S3 Standard-IA is a storage class that is designed for infrequently accessed data. It offers lower storage costs than S3 Standard, but it has a retrieval latency of 1-5 minutes.
Comment: Highly available so One Zone IA is out the question Glacier Deep archive isn't immediately accessible 12-48 hours B is the answer.
Comment: S3 Glacier Deep Archive is intended for data that is rarely accessed and can tolerate retrieval times measured in hours. Moving data to S3 One Zone-IA immediately would not meet the requirement of immediate accessibility with the same high availability and resiliency.
Comment: The answer should be C. S3 One Zone-IA is for data that is accessed less frequently but requires rapid access when needed. Unlike other S3 Storage Classes which store data in a minimum of three Availability Zones (AZs), S3 One Zone-IA stores data in a single AZ and costs 20% less than S3 Standard-IA. https://aws.amazon.com/s3/storage-classes/#:~:text=S3%20One%20Zone%2DIA%20is,less%20than%20S3%20Standard%2DIA.
Comment: The Question emphasises to kepp same high availability class - S3 One Zone-IA doesnt support multiple Availability Zone data resilience model like S3 Standard-Infrequent Access.
Comment: Needs immediate accessibility after 30days, IF they need to be accessed.
Comment: S3 Standard-Infrequent Access after 30 days
Comment: B Option B - Move the data objects to S3 Standard-Infrequent Access (S3 Standard-IA) after 30 days - will meet the requirements of keeping the data immediately accessible with high availability and resiliency, while minimizing storage costs. S3 Standard-IA is designed for infrequently accessed data, and it provides a lower storage cost than S3 Standard, while still offering the same low latency, high throughput, and high durability as S3 Standard.
Comment: A because Elasticache, despite being ideal for leaderboards per Amazon, doesn't cache at edge locations. D because FSx has higher performance for low latency needs. https://www.techtarget.com/searchaws/tip/Amazon-FSx-vs-EFS-Compare-the-AWS-file-services "FSx is built for high performance and submillisecond latency using solid-state drive storage volumes. This design enables users to select storage capacity and latency independently. Thus, even a subterabyte file system can have 256 Mbps or higher throughput and support volumes up to 64 TB."
Comment: Just to add, ElastiCache is use in front of AWS database.
Comment: Why not EFS?
Comment: The reasons are: Storing static files in S3 with CloudFront provides durability, high availability, and low latency by caching at edge locations. FSx for Windows File Server provides a fully managed Windows native file system that can be accessed from the Windows EC2 instances to share server-side code. It is designed for high availability and scales up to 10s of GBPS throughput. EFS and EBS volumes can be attached to a single AZ. FSx and S3 are replicated across AZs for high availability.
Comment: A because Elasticache doesn't cache at edge locations. D because FSx has higher performance for low latency needs.
Comment: The question and options are badly worded. How does (D) storing server side code on a file server makes it executable?
Comment: you can't mount efs on windows
Comment: A & D for sure
Comment: It is obvious that A and D.
Comment: both A and D seem correct
Comment: A and D seems correct
Comment: Use a Lambda@Edge function with an external image management library. Associate the Lambda@Edge function with the CloudFront behaviors that serve the images. Using a Lambda@Edge function with an external image management library is the best solution to resize the images dynamically and serve appropriate formats to clients. Lambda@Edge is a serverless computing service that allows running custom code in response to CloudFront events, such as viewer requests and origin requests. By using a Lambda@Edge function, it's possible to process images on the fly and modify the CloudFront response before it's sent back to the client. Additionally, Lambda@Edge has built-in support for external libraries that can be used to process images. This approach will reduce operational overhead and scale automatically with traffic.
Comment: The moment there is a need to implement some logic at the CDN think Lambda@Edge.
Comment: The correct answer is C. A Lambda@Edge function is a serverless function that runs at the edge of the CloudFront network. This means that the function is executed close to the user, which can improve performance. An external image management library can be used to resize images and to serve the appropriate format. Associating the Lambda@Edge function with the CloudFront behaviors that serve the images ensures that the function is executed for all requests that are served by those behaviors.
Comment: If the user asks for the most optimized image format (JPEG,WebP, or AVIF) using the directive format=auto, CloudFront Function will select the best format based on the Accept header present in the request. Latest documentation: https://aws.amazon.com/blogs/networking-and-content-delivery/image-optimization-using-amazon-cloudfront-and-aws-lambda/
Comment: But a policy alone cannot resize images.
Comment: https://aws.amazon.com/cn/blogs/networking-and-content-delivery/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/
Comment: https://aws.amazon.com/cn/blogs/networking-and-content-delivery/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/
Comment: Option C is correct because it allows the compliance team to manage the KMS keys used for server-side encryption, thereby providing the necessary control over the encryption keys. Additionally, the use of the "aws:SecureTransport" condition on the bucket policy ensures that all connections to the S3 bucket are encrypted in transit. option B might be misleading but using SSE-S3, the encryption keys are managed by AWS and not by the compliance team
Comment: Perfect explanation. I Agree
Comment: Not A, Certificate Manager has nothing to do with S3 Not B, SSE-S3 does not allow compliance team to manage the key Not D, Macie is for identifying sensitive data, not protecting it
Comment: Macie does not encrypt the data like the question is asking https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html Also, SSE-S3 encryption is fully managed by AWS so the Compliance Team can't administer this.
Comment: D - Can't be because - Amazon Macie is a data security service that uses machine learning (ML) and pattern matching to discover and help protect your sensitive data. Macie discovers sensitive information, can help in protection but can't protect
Comment: B can work if they do not want control over encryption keys.
Comment: Option A proposes creating a public SSL/TLS certificate in AWS Certificate Manager and associating it with Amazon S3. This step ensures that data is encrypted in transit. Then, the default encryption for each S3 bucket will be configured to use server-side encryption with AWS KMS keys (SSE-KMS), which will provide encryption at rest for the data stored in S3. In this solution, the compliance team will manage the KMS keys, ensuring that they control the encryption keys for data at rest.
Comment: ACM cannot be integrated with Amazon S3 bucket directly.
Comment: ACM is for website certificates, has nothing to do with S3.
Comment: Option C seems to be the correct answer, option A is also close but ACM cannot be integrated with Amazon S3 bucket directly, hence, u can not attached TLS to S3. You can only attached TLS certificate to ALB, API Gateway and CloudFront and maybe Global Accelerator but definitely NOT EC2 instance and S3 bucket
Comment: D makes no sense.
Comment: Correct Answer is "C" “D” is not correct because Amazon Macie securely stores your data at rest using AWS encryption solutions. Macie encrypts data, such as findings, using an AWS managed key from AWS Key Management Service (AWS KMS). However, in the question there is a requirement that the compliance team must administer the encryption key for data at rest. https://docs.aws.amazon.com/macie/latest/user/data-protection.html
Comment: Option C will meet the requirements. Explanation: The compliance team needs to administer the encryption key for data at rest in order to ensure that protected health information (PHI) is encrypted in transit and at rest. Therefore, we need to use server-side encryption with AWS KMS keys (SSE-KMS). The default encryption for each S3 bucket can be configured to use SSE-KMS to ensure that all new objects in the bucket are encrypted with KMS keys. Additionally, we can configure the S3 bucket policies to allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition. This ensures that the data is encrypted in transit.
Comment: We must provide encrypted in transit and at rest. Macie is needed to discover and recognize any PII or Protected Health Information. We already know that the hospital is working with the sensitive data ) so protect them witn KMS and SSL. Answer D is unnecessary
Comment: Macie does not encrypt the data like the question is asking https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html Also, SSE-S3 encryption is fully managed by AWS so the Compliance Team can't administer this.
Comment: C [Correct]: Ensures Https only traffic (encrypted transit), Enables compliance team to govern encryption key. D [Incorrect]: Misleading; PHI is required to be encrypted not discovered. Maice is a discovery service. (https://aws.amazon.com/macie/)
Comment: Correct answer should be D. "Use Amazon Macie to protect the sensitive data..." As requirement says "The hospitals's compliance team must ensure that all protected health information (PHI) is encrypted in transit and at rest." Macie protects personal record such as PHI. Macie provides you with an inventory of your S3 buckets, and automatically evaluates and monitors the buckets for security and access control. If Macie detects a potential issue with the security or privacy of your data, such as a bucket that becomes publicly accessible, Macie generates a finding for you to review and remediate as necessary.
Comment: Option C should be
Comment: an interface endpoint is a horizontally scaled, redundant VPC endpoint that provides private connectivity to a service. It is an elastic network interface with a private IP address that serves as an entry point for traffic destined to the AWS service. Interface endpoints are used to connect VPCs with AWS services
Comment: C. Use a gateway endpoint is wrong because gateway endpoints only support for S3 and dynamoDB, so B is correct
Comment: B. Use an interface endpoint. Here's the reasoning: Interface Endpoint (Option B): An interface endpoint (also known as VPC endpoint) allows communication between resources in your VPC and services without traversing the public internet. In this case, you can create an interface endpoint for API Gateway in your VPC. This enables the communication between the BuyStock and CheckFunds RESTful web services within the VPC, and it doesn't require significant changes to the code. X-API-Key header (Option A): Adding an X-API-Key header for authorization doesn't address the issue of ensuring that the APIs communicate through the VPC. It's more related to authentication and authorization mechanisms.
Comment: The question here is that the BuyStock RESTful web service calls the CheckFunds RESTful web service through API gateway (internet), not directly. How does API gateway connect the services BuyStock and CheckFunds? It connects the Interface Endpoint of the services through Privatelink. The interface endpoints provide direct connection between services within the same private subnet. Answer B is correct.
Comment: how is it even possible, I mean if it's private and both are in the same VPC then we shouldn't even have such an issue right?
Comment: B. Use an interface endpoint.
Comment: Answer B (from abylead) With API GW, you can create multiple prv REST APIs, only accessible with an interface VPC endpt. To allow/ deny simple or cross acc access to your API from selected VPCs & its endpts, you use resource plcys. In addition, you can also use DX for a connection between onprem network to VPC or your prv API. API GW to VPC: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html Less correct & incorrect (infeasible & inadequate) answers: A)X-API-Key in HTTP header for authorization needs auto-process fcts & changes: inadequate. C)VPC GW endpts for S3 or DynamDB aren't for RESTful svcs: infeasible. D)SQS que between 2 REST APIs needs endpts & some changes: inadequate.
Comment: I select C because it's the solution with the " FEWEST changes to the code"
Comment: Fewest changes to the code doesn't mean break the code by doing something irrelevant. Gateway endpoint is for S3 and DynamoDB
Comment: Gateway Endpoint can provide access to S3 or DynamoDB, not to API Gateway
Comment: An interface endpoint is powered by PrivateLink, and uses an elastic network interface (ENI) as an entry point for traffic destined to the service
Comment: BBBBBB
Comment: https://www.linkedin.com/pulse/aws-interface-endpoint-vs-gateway-alex-chang
Comment: Correct answer is B. Incorrectly selected C
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html
Comment: The only time where an Interface Endpoint may be preferable (for S3 or DynamoDB) over a Gateway Endpoint is if you require access from on-premises, for example you want private access from your on-premise data center
Comment: The RESTful services is neither an S3 or DynamDB service, so a VPC Gateway endpoint isn't available here.
Comment: fewest changes to code and below link: https://gkzz.medium.com/what-is-the-differences-between-vpc-endpoint-gateway-endpoint-ae97bfab97d8
Comment: This really helped me understand the difference between the two. Thx
Comment: Agreed B
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html - Interface EP
Comment: would be nice to have an explanation on why examtopic selects its answers.
Comment: exam topic does not select anything, these are questions from the free forum topics, the only thing exam topic does is to aggregate them all under one single point of view and if you pay you get to see them all aggregated else you can still scroll topic by topic for free
Comment: DAX delivers up to a 10 times performance improvement—from milliseconds to microseconds. Using DynamoDB export to S3, you can export data from an Amazon DynamoDB table to an Amazon S3 bucket. This feature enables you to perform analytics and complex queries on your data using other AWS services such as Athena, AWS Glue.
Comment: test test
Comment: Sub-millisecond: DynamoDB (DAX), onetime query, Least operational overhead: Athena
Comment: Dynamo DB + DAX = low latency.
Comment: Scusate io ho pagato contributor perchè vedo ancora + votati invece di vedere solo la risposta corretta? Grazie.Fabio
Comment: Vedrai sempre e comunque sia la risposta della community ("Most Voted") che la risposta degli admin (rettangolo verde). Occhio perche' la risposta degli admin non sempre e' corretta.
Comment: Sub-millisecond latency == DAX
Comment: So C !
Comment: Amazon DynamoDB with DynamoDB Accelerator (DAX) is a fully managed, in-memory caching solution for DynamoDB. DAX can improve the performance of DynamoDB by up to 10x. This makes it a good choice for data that needs to be accessed with sub-millisecond latency. DynamoDB table export allows you to export data from DynamoDB to an S3 bucket. This can be useful for running one-time queries on historical data. Amazon Athena is a serverless, interactive query service that makes it easy to analyze data in Amazon S3. Athena can be used to run one-time queries on the data in the S3 bucket.
Comment: A NoSQL isn't even mentioned in the question and yet we are supposed to just imagine this fictional customer is using a NoSql DB
Comment: C Amazon DynamoDB with DynamoDB Accelerator (DAX): DynamoDB is a fully managed NoSQL database service provided by AWS. It is designed for low-latency access to frequently accessed data. DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that can significantly reduce read latency, making it suitable for achieving sub-millisecond read times.
Comment: C is correct A don't meets a requirement (LEAST operational overhead) because use script B: Not regarding to require D: Kinesis for near-real-time (Not for read) -> C is correct
Comment: Agreed C will be best because of DynamoDB DAX
Comment: Option C will be the best fit. As they would like to retrieve the data with sub-millisecond, DynamoDB with DAX is the answer. DynamoDB supports some of the world's largest scale applications by providing consistent, single-digit millisecond response times at any scale. You can build applications with virtually unlimited throughput and storage.
Comment: C is the correct answer
Comment: Option C is the right one. The questions clearly states "sub-millisecond latency "
Comment: https://aws.amazon.com/dynamodb/dax/?nc1=h_ls
Comment: Cccccccccccc
Comment: Option B is preferred over A because Amazon Kinesis Data Streams inherently maintain the order of records within a shard, which is crucial for the given requirement of preserving the order of messages for a particular payment ID. When you use the payment ID as the partition key, all messages for that payment ID will be sent to the same shard, ensuring that the order of messages is maintained. On the other hand, Amazon DynamoDB is a NoSQL database service that provides fast and predictable performance with seamless scalability. While it can store data with partition keys, it does not guarantee the order of records within a partition, which is essential for the given use case. Hence, using Kinesis Data Streams is more suitable for this requirement. As DynamoDB does not keep the order, I think BE is the correct answer here.
Comment: I don't understand the question. The only requirement is: " system that requires messages for a particular payment ID to be received in the same order that they were sent" SQS FIFO (E) meets this requirement. Why would you "write the message" to Kinesis or DynamoDB anymore. There is no streaming or DB storage requirement in the question. Between A/B, B is better logically but it doesn't meet any stated requirement. Happy to understand what I'm missing
Comment: Instead of "what actions...", the question should say "what are the alternatives/options that meet this requirement".
Comment: Both Kinesis and SQS FIFO queue guarantee the order, other answers don't.
Comment: Option B (Write the messages to an Amazon Kinesis data stream with the payment ID as the partition key): Kinesis can provide ordered processing within a shard Write the messages to an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Set the message group to use the payment ID. SQS FIFO (First-In-First-Out) queues preserve the order of messages within a message group.
Comment: Technically both B and E will ensure processing order, but SQS FIFO was specifically built to handle this requirement. There is no ask on how to store the data so A and C are out.
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html
Comment: options D and E are better because they mimic a real-world queue system and ensure that payments are processed in the correct order, just like customers in a store would be served in the order they arrived. This is crucial for a payment processing system where order matters to avoid mistakes in payment processing.
Comment: Amazon Kinesis Data Streams Overkill for Ordering Overkill for Ordering: While Kinesis can maintain order within a partition key, it might be seen as overkill for a scenario where your primary concern is maintaining the order of payments. SQS FIFO queues (option E) are specifically designed for this purpose and provide an easier and more cost-effective solution.
Comment: AAAAAAAAA EEEEEEEEEEEEEE
Comment: IF the question would be "Choose all the solutions that fulfill these requirements" I would chosen BE. But it is: "Which actions should a solutions architect take to meet this requirement? " For this reason I chose AE, because we don't need both Kinesis AND SQS for this solution. Both choices complement to order processing: order stored in DB, work item goes to the queue.
Comment: Incorrect, AWS will clarify it by using the phrase - "combination of actions".
Comment: E --> no doubt B --> see https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html
Comment: 1) SQS FIFO queues guarantee that messages are received in the exact order they are sent. Using the payment ID as the message group ensures all messages for a payment ID are received sequentially. 2) Kinesis data streams can also enforce ordering on a per partition key basis. Using the payment ID as the partition key will ensure strict ordering of messages for each payment ID.
Comment: The other options do not guarantee message ordering. DynamoDB and ElastiCache are not message queues. SQS standard queues deliver messages in approximate order only.
Comment: BE no doubt.
Comment: Option A, writing the messages to an Amazon DynamoDB table, would not necessarily preserve the order of messages for a particular payment ID
Comment: I don´t unsderstand A, How you can guaratee the order with DynamoDB?? The order is guarantee with SQS FIFO and Kinesis Data Stream in 1 shard...
Comment: If it really means "combination of actions" than A+E would work, because you'd use the FIFO queue (E) to guarantee the order. Then the order in the database doesn't matter. If they want to alternative solutions then obviously B and E would work while A alone doesn't.
Comment: AE is the answer
Comment: dynamodb or kinesis data stream which one in order?
Comment: No doubt )
Comment: I don't honestly / can't understand why people go to ChapGPT to ask for the answers.... if I recall correctly they only consolidated their DB until 2021...
Comment: Yup, ChatGPT doesn't //know// anything about AWS services. It only repeats what other people have said about it, which could be nonsense or hyperbole or some combination thereof.
Comment: The answer is B la. SNS FIFO topics queue should be used combined with SQS FIFO queue in this case. The question asked for correct order to different event, so asking for SNS fan out here to send to individual SQS. https://docs.aws.amazon.com/sns/latest/dg/fifo-example-use-case.html
Comment: B is correct, but this is not about SNS -> SQS fan-out, it's not necessary. Just SNS FIFO for ordered pub/sub messaging.
Comment: The best answer!
Comment: SNS can have many-to-many relations, while SQS supports only one consumer at a time (many-to-one).
Comment: First time in my life that the answer is actually SNS
Comment: AWS does not currently offer FIFO topics for SNS. SNS only supports standard topics, which do not guarantee message order.
Comment: I'm creating a topic right now and I have both types to choose.
Comment: Even chat gpt said B
Comment: Yes, you can technically do this with SQS FIFO partitioned queue by giving separate group ID's to leaderboard, matchmaking etc but this is not as useful as SNS FIFO and is overkill as no need for storage etc. B is more elegant and concise solution,
Comment: Guys, ChatGPT sucks !. Try removing [most voted] from choice B and it will choose D. And if you put [most voted] in front of A, it will select A. LOL !
Comment: just know SNS FIFO also can send events or messages cocurrently to many subscribers while maintaining the order it receives. SNS fanout pattern is set in standard SNS which is commonly used to fan out events to large number of subscribers and usually for duplicated messages.
Comment: SQS looks like a good idea first, but since we have to send the same message to multiple destination, even if SQS could do it, SNS is much more dedicated to this kind of usage.
Comment: My Answer is B https://docs.aws.amazon.com/sns/latest/dg/sns-fifo-topics.html You can use Amazon SNS FIFO (first in, first out) topics with Amazon SQS FIFO queues to provide strict message ordering and message deduplication. The FIFO capabilities of each of these services work together to act as a fully managed service to integrate distributed applications that require data consistency in near-real time. Subscribing Amazon SQS standard queues to Amazon SNS FIFO topics provides best-effort ordering and at least once delivery.
Comment: bbbbbbbbbbbbbbb
Comment: SQS FIFO maintains the order of the events - Answer is D
Comment: It should be the fan-out pattern, and the pattern starts with Amazon SNS FIFO for the orders.
Comment: Answer is D. You are so lazy because instead of searching in documentation or your notes, you are asking ChatGPT. Do you really think you will take this exam ? Hint: ask ChatGPT
Comment: D is correct (SQS FIFO) Because B can't send event concurrently though it can send in the order of the events
Comment: Amazon SNS is a highly available and durable publish-subscribe messaging service that allows applications to send messages to multiple subscribers through a topic. SNS FIFO topics are designed to ensure that messages are delivered in the order in which they are sent. This makes them ideal for situations where message order is important, such as in the case of the company's game system. Option A, Amazon EventBridge event bus, is a serverless event bus service that makes it easy to build event-driven applications. While it supports ordering of events, it does not provide guarantees on the order of delivery.
Comment: read this: https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html
Comment: good call.. that confirms on that page: Important All requests to topics with SSE enabled must use HTTPS and Signature Version 4. For information about compatibility of other services with encrypted topics, see your service documentation. Amazon SNS only supports symmetric encryption KMS keys. You cannot use any other type of KMS key to encrypt your service resources. For help determining whether a KMS key is a symmetric encryption key, see Identifying asymmetric KMS keys.
Comment: My god! Every other question is about SQS! I thought this was AWS Solution Architect test not "How to solve any problem in AWS using SQS" test!
Comment: A and C involve 'updating the default key policy' which is not something you. Either you create a key policy, OR AWS assigns THE "default key policy". E 'applies an IAM policy to restrict key usage to a set of authorized principals' which is not how IAM policies work. You can 'apply an IAM policy to restrict key usage', but it would be restricted to the principals who have the policy attached; you can't specify them in the policy. Leaves B and D. That B lacks the TLS statement is irrelevant because "all requests to topics with SSE enabled must use HTTPS" anyway.
Comment: Yes, BD is correct. "All requests to queues with SSE enabled must use HTTPS and Signature Version 4." -> valid for SNS and SQS alike: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html "Set a condition in the queue policy to allow only encrypted connections over TLS." refers to the "aws:SecureTransport" condition, but it's actually redundant.
Comment: Its only options C and D that covers encryption on transit, encryption at rest and a restriction policy.
Comment: Answer is BD SNS: AWS KMS, key policy, SQS: AWS KMS, Key policy
Comment: "IAM policies you can't specify the principal in an identity-based policy because it applies to the user or role to which it is attached" reference: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/security_iam_service-with-iam.html that excludes E
Comment: Encryption at transit = use SSL/TLS -> rule out A,B Encryption at rest = encryption on components -> keep C, D, E KMS always need a key policy, IAM is optional -> E out -> C, D left, one for SNS, one for SQS. TLS: checked, encryption on components: checked
Comment: Answer is BD SNS: AWS KMS, key policy, SQS: AWS KMS, Key policy
Comment: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-data-encryption.html You can protect data in transit using Secure Sockets Layer (SSL) or client-side encryption. You can protect data at rest by requesting Amazon SQS to encrypt your messages before saving them to disk in its data centers and then decrypt them when the messages are received. https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html A key policy is a resource policy for an AWS KMS key. Key policies are the primary way to control access to KMS keys. Every KMS key must have exactly one key policy. The statements in the key policy determine who has permission to use the KMS key and how they can use it. You can also use IAM policies and grants to control access to the KMS key, but every KMS key must have a key policy.
Comment: CD B does not include encryption in transit.
Comment: in transit is included in D. With C, not include encrytion at rest.... Server-side will include it.
Comment: That was my objection toward option B. CD cover both encryption at Rest and Server-Side_Encryption
Comment: ChatGPT returned AD as a correct answer)
Comment: B: To encrypt data at rest, we can use a customer-managed key stored in AWS KMS to encrypt the SNS components. E: To restrict access to the data and allow only authorized personnel to access the data, we can apply an IAM policy to restrict key usage to a set of authorized principals. We can also set a condition in the queue policy to allow only encrypted connections over TLS to encrypt data in transit.
Comment: For a customer managed KMS key, you must configure the key policy to add permissions for each queue producer and consumer. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-key-management.html
Comment: bebebe
Comment: bdbdbdbd All KMS keys must have a key policy. IAM policies are optional.
Comment: Amazon RDS provides automated backups, which can be configured to take regular snapshots of the database instance. By enabling automated backups and setting the retention period to 30 days, the company can ensure that it retains backups for up to 30 days. Additionally, Amazon RDS allows for point-in-time recovery within the retention period, enabling the restoration of the database to its state from any point within the last 30 days, including 5 minutes before any change. This feature provides the required capability to recover from accidental data loss incidents.
Comment: Automated backups allow you to recover your database to any point in time within your specified retention period, which can be up to 35 days. The recovery process creates a new Amazon RDS instance with a new endpoint, and the process takes time proportional to the size of the database. Automated backups are enabled by default and occur daily during the backup window. This feature provides an easy and convenient way to recover from data loss incidents such as the one described in the scenario.
Comment: Option C, Automated backups, will meet the requirement. Amazon RDS allows you to automatically create backups of your DB instance. Automated backups enable point-in-time recovery (PITR) for your DB instance down to a specific second within the retention period, which can be up to 35 days. By setting the retention period to 30 days, the company can restore the database to its state from up to 5 minutes before any change within the last 30 days.
Comment: I selected C as well, but still don't know how the automatic backup could have a copy 5 minutes before any change. AWS doc states "Automated backups occur daily during the preferred backup window. " https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html. I think the answer maybe A, as read replica will be kept sync and then restore from the read replica. could an expert help?
Comment: Automated backups enable point-in-time recovery (PITR) for your DB instance down to a specific second within the retention period, which can be up to 35 days
Comment: "the company wants the ability to restore the database to its state from 5 minutes before any change" The automatic backup takes a backup every 5 minutes. This means it can restore the database to 5 minutes in the past.
Comment: C: Automated Backups https://aws.amazon.com/rds/features/backup/
Comment: Automated Backups...
Comment: ccccccccc
Comment: Implementing API usage plans and API keys is a straightforward way to restrict access to specific users or groups based on subscriptions. It allows you to control access at the API level and doesn't require extensive changes to your existing architecture. This solution provides a clear and manageable way to enforce access restrictions without complicating other parts of the application
Comment: Chat GPT said: Option C, "Apply fine-grained IAM permissions to the premium content in the DynamoDB table," would likely involve the least operational overhead. Here's why: Granular Control: IAM permissions allow you to control access at a very granular level, including specific actions (e.g., GetItem, PutItem) on individual resources (e.g., DynamoDB tables). Integration with Cognito: IAM policies can be configured to allow access based on the identity of the user authenticated through Cognito. You can create IAM roles or policies that grant access to users with specific attributes or conditions, such as having a subscription. Minimal Configuration Changes: This solution primarily involves configuring IAM policies for access control in DynamoDB, which can be done with minimal changes to the existing application architecture.
Comment: C is correct as per the link and doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html#apigateway-usage-plans-best-practices D: API keys cannot be used to limit access and this can only be done via methods defined in above link
Comment: I had to chose D but must have clicked C incorrectly. It is D as my explanation is about D not C! C is the wrong answer.
Comment: Also, option A is for performance and not for security option B, WAF cannot control access based on subscription without massive custom coding which will be a big operational overhead
Comment: In the same document https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html if you scroll down, it says `Don't use API keys for authentication or authorization to control access to your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, to control access to your API, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.` In the same document at the bottom, it says "If you're using a developer portal to publish your APIs, note that all APIs in a given usage plan are subscribable, even if you haven't made them visible to your customers." I go with C
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html#apigateway-usage-plans-best-practices Correct link
Comment: After you create, test, and deploy your APIs, you can use API Gateway usage plans to make them available as product offerings for your customers. You can configure usage plans and API keys to allow customers to access selected APIs, and begin throttling requests to those APIs based on defined limits and quotas. These can be set at the API, or API method level. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html#:~:text=Creating%20and%20using-,usage%20plans,-with%20API%20keys
Comment: D Option D involves implementing API usage plans and API keys. By associating specific API keys with users who have a valid subscription, you can control access to the premium content.
Comment: A. This would not actually limit access based on subscriptions. It helps optimize and control API usage, but does not address the core requirement. B. This could work by checking user subscription status in the WAF rule, but would require ongoing management of WAF and increases operational overhead. C. This is a good approach, using IAM permissions to control DynamoDB access at a granular level based on subscriptions. However, it would require managing IAM permissions which adds some operational overhead. D. This option uses API Gateway mechanisms to limit API access based on subscription status. It would require the least amount of ongoing management and changes, minimizing operational overhead. API keys could be easily revoked/changed as subscription status changes.
Comment: CD both possible but D is more suitable since it mentioned in https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html A,B not relevant.
Comment: The solution that will meet the requirement with the least operational overhead is to implement API Gateway usage plans and API keys to limit access to premium content for users who do not have a subscription. Option A is incorrect because API caching and throttling are not designed for authentication or authorization purposes, and it does not provide access control. Option B is incorrect because although AWS WAF is a useful tool to protect web applications from common web exploits, it is not designed for authorization purposes, and it might require additional configuration, which increases the operational overhead. Option C is incorrect because although IAM permissions can restrict access to data stored in a DynamoDB table, it does not provide a mechanism for limiting access to specific content based on the user subscription. Moreover, it might require a significant amount of additional IAM permissions configuration, which increases the operational overhead.
Comment: To meet the requirement with the least operational overhead, you can implement API usage plans and API keys to limit the access of users who do not have a subscription. This way, you can control access to your API Gateway APIs by requiring clients to submit valid API keys with requests. You can associate usage plans with API keys to configure throttling and quota limits on individual client accounts.
Comment: answer is D ,if looking for least overhead https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html C will achieve it but operational overhead is high.
Comment: Both C&D are valid solution According to ChatGPT: "Applying fine-grained IAM permissions to the premium content in the DynamoDB table is a valid approach, but it requires more effort in managing IAM policies and roles for each user, making it more complex and adding operational overhead."
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html
Comment: ccccccccc
Comment: "Fine-grained permissions" for only two groups of users, hell no. "IAM permissions" for customers, also no.
Comment: NLBs allow UDP traffic (ALBs don't support UDP) Global Accelerator uses Anycast IP addresses and its global network to intelligently route users to the optimal endpoint Using NLBs as Global Accelerator endpoints provides improved availability and DDoS protection.
Comment: Non-HTTP, Massive performance: NLB, UDP: AWS Global Accelerator
Comment: Neither ALB (B+D) nor CloudFront (C+D) do support UDP.
Comment: UDP = NLB and Global Accelerator
Comment: NLB + GA support UDP/TCP
Comment: good reference https://blog.cloudcraft.co/alb-vs-nlb-which-aws-load-balancer-fits-your-needs/
Comment: C - D: Cloudfront don't support UDP/TCP B: Global accelerator don't support ALB A is correct
Comment: UDP = NBL UDP = GLOBAL ACCELERATOR UPD NOT WORKING WITH CLOUDFRONT ANS IS A
Comment: More discussions at: https://www.examtopics.com/discussions/amazon/view/51508-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Why is C not correct - does anyone know?
Comment: It could be valid but I think A is better. Uses the AWS global network to optimize the path from users to applications, improving the performance of TCP and UDP traffic
Comment: Latency based routing is already using in the application, so AWS global network will optimize the path from users to applications.
Comment: UDP == NLB Must be hosted on-premises != CloudFront
Comment: actually CloudFront's origin can be on-premises. Source: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html#concept_CustomOrigin "A custom origin is an HTTP server, for example, a web server. The HTTP server can be an Amazon EC2 instance or an HTTP server that you host somewhere else. "
Comment: aaaaaaaa
Comment: i get confused, the question saids "NEW" users... if you apply this password policy it would affect all the users in the AWS account....
Comment: The question is for new users, answer A is not exact for that case.
Comment: Because its mentioned "all new users"
Comment: Ignore the above, seems to be custom policy can help in the case, so A should be right
Comment: You can set a custom password policy on your AWS account to specify complexity requirements and mandatory rotation periods for your IAM users' passwords. When you create or change a password policy, most of the password policy settings are enforced the next time your users change their passwords. However, some of the settings are enforced immediately. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html#:~:text=Setting%20an%20account-,password%20policy,-for%20IAM%20users
Comment: To accomplish this, the solutions architect should set an overall password policy for the entire AWS account. This policy will apply to all IAM users in the account, including new users.
Comment: Set overall password policy ...
Comment: A is correct
Comment: aaaaaaa
Comment: question said "These tasks were written by different teams and have no common programming language", and key word "scalable". Only Lambda can fulfil these. Lambda can be done in different programming languages, and it is scalable
Comment: AWS Batch - As a fully managed service, AWS Batch helps you to run batch computing workloads of any scale. AWS Batch automatically provisions compute resources and optimizes the workload distribution based on the quantity and scale of the workloads. With AWS Batch, there's no need to install or manage batch computing software, so you can focus your time on analyzing results and solving problems. https://docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html ---> I am voting for A, C would have been OK if the time was within 15 minutes.
Comment: It's not because time limit of lambda is 15 minutes
Comment: But the question states "several 1-hour tasks on a schedule", and the maximum runtime for Lambda is 15 minutes, so it can't be A.
Comment: can't be C
Comment: Lambda can only execute job under 15 mins* so C can't be the answer
Comment: "Running on a schedule" = Batch Not C due Lambda < 15 min Not D, auto-scaling doesn't make sense for things running on a schedule
Comment: Answer = D "performance and scalability while these tasks run on a single instance" They gave me a legacy application and want it to autoscale for performace. They dont want it to run on a single EC2 instance. Shouldn't I make an AMI and provision multiple EC2 instances in an autoscaling group ? I could put an ALB in front of it. I wont have to deal with "uncommon programming languages" inside the application... Just a thought..
Comment: AWS Batch is for jobs running at schedule on EC2. so option A B is operational overhead C Lambda is 15 mins max execution D Scaling is not a requirement
Comment: AWS Batch: AWS Batch is a fully managed service for running batch computing workloads. It dynamically provisions the optimal quantity and type of compute resources based on the volume and specific resource requirements of the batch jobs. It allows you to run tasks written in different programming languages with minimal operational overhead.
Comment: The tast working for hour but lambda function timeout is 15 minutes. So vote A.
Comment: I know guys are stressed out trying to figure this exam out okay, but no matter what people say, with or without reasoning, at least put your mouth clean. Going like AAA is an issue, but talking shi* on him just because he didn't write down the reasoning is your fault.
Comment: It can run heterogeneous workloads and tasks without needing to convert them to a common format. AWS Batch manages the underlying compute resources - no need to manage containers, Lambda functions or Auto Scaling groups.
Comment: AWS Lambda function can only be run for 15 mins
Comment: maximum runtime for Lambda is 15 minutes, hence A
Comment: I also go with A.
Comment: C. Copy the tasks into AWS Lambda functions. Schedule the Lambda functions by using Amazon EventBridge (Amazon CloudWatch Events)
Comment: wrong, Lambda maximum runtime is 15 minutes and the tasks run for an hour
Comment: B and D out! A and C let's think! AWS Lambda functions are time limited. So, Option A
Comment: AAAAAAAAAAAAAAAAA because lambda only run within 15 minutes
Comment: Answer is A. Could have been C but AWS Lambda functions can be only configured to run up to 15 minutes per execution. While the task in question need an 1hour to run,
Comment: question is asking for the LEAST operational overhead. With batch, you have to create the compute environment, create the job queue, create the job definition and create the jobs --> more operational overhead than creating an ASG
Comment: Things 'running on a schedule' = Batch, not autoscaling
Comment: A not C The maximum AWS Lambda function run time is 15 minutes. If a Lambda function runs for longer than 15 minutes, it will be terminated by AWS Lambda. This limit is in place to prevent the Lambda environment from becoming stale and to ensure that resources are available for other functions. If a task requires more than 15 minutes to complete, a different AWS service or architecture may be better suited for the use case.
Comment: "The company needs a managed solution that minimizes operational maintenance" Watch out for NAT instances vs NAT Gateways. As the company needs a managed solution that minimizes operational maintenance - NAT Gateway is a public subnet is the answer.
Comment: C https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-network-internet-NAT-gateway.html ...and a NAT gateway in a public subnet.
Comment: This meets the requirements for a managed, low maintenance solution for private subnets to access the internet: NAT gateway provides automatic scaling, high availability, and fully managed service without admin overhead. Placing the NAT gateway in a public subnet with proper routes allows private instances to use it for internet access. Minimal operational maintenance compared to NAT instances.
Comment: No good: NAT instances (A, B) require more hands-on management. Placing a NAT gateway in a private subnet (D) would not allow internet access.
Comment: C Nat gateway can't deploy in a private subnet.
Comment: minimizes operational maintenance = NGW
Comment: C..provision NGW in Public Subnet
Comment: ccccc is the best
Comment: ccccccccc
Comment: https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html#:~:text=encrypted%20Amazon%20EBS%20volumes%20without%20using%20a%20launch%20template%2C%20encrypt%20all%20new%20Amazon%20EBS%20volumes%20created%20in%20your%20account.
Comment: If you want to encrypt Amazon EBS volumes for your nodes, you can deploy the nodes using a launch template. To deploy managed nodes with encrypted Amazon EBS volumes without using a launch template, encrypt all new Amazon EBS volumes created in your account. For more information, see Encryption by default in the Amazon EC2 User Guide for Linux Instances.
Comment: Quickly rule out A (which plugin? > overhead) and E because of bad practice Among B,C,D: B and C are functionally similar > choice must be between B or C, D is fixed Between B and C: C is out since it set default for all EBS volume in the region, which is more than required and even wrong, say what if other EBS volumes of other applications in the region have different requirement?
Comment: (C) is correct; the EBS volumes of other applications in the region will not be affected bc an IAM role will limit the encryption key to the EKS cluster.
Comment: A and E are obvious nos. D is a shoo-in. The difference between B&C is basicually EBS encrption by default vs encrption. Encryption by default is by region, and encrypt everything in that region going forward, versus simple encryption is volume by volume, C is less operational overhead. Check doc & chatGPT.
Comment: this one is going on my skip list
Comment: Don't it came for me in my exam today xd
Comment: If question is giving a requirement related to a particular case and asking to encrypt all data at rest; it is clear that encryption is for this case only and not for other projects in entire region. so option B is more appropriate along with option D.
Comment: It says: 'The company must encrypt ALL data at rest', so there is nothing wrong with 'enabling EBS encryption by default' . C & D
Comment: B&D are correct. C is wrong because when you turn on encryption by defaul, AWS uses its own key while the requirement is using Customer key. Detail is here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default
Comment: Not A (avoid 3rd party plugins when there are native services) Not C ("encryption by default" would impact other services) Not E (Keys belong in KMS, not in EKS cluster)
Comment: "The company must encrypt all data at rest by using a customer managed key that is stored in AWS Key Management Service (AWS KMS)." I am just a bit concerned that the question does not put any limits on not encrypting all the EBS by default in the account. Both B and C can work. C is a hack but it is definitely LEAST operational overhead. Also, we don't know if there are other services or not that may be impacted. What do you think?
Comment: EBS encryption is set regionally. AWS account is global but it does not mean EBS encryption is enable by default at account level. default EBS encryption is a regional setting within your AWS account. Enabling it in a specific region ensures that all new EBS volumes created in that region are encrypted by default, using either the default AWS managed key or a customer managed key that you specify.
Comment: "Enabling it in a specific region ensures that all new EBS volumes created in that region are encrypted by default" which is not what we want. We want to encrypt the EBS volumes used by this EKS cluster, NOT "all new EBS volumes created in that region."
Comment: IF you need to encrypt an unencrypted volume, • Create an EBS snapshot of the volume • Encrypt the EBS snapshot ( using copy ) • Create new EBS volume from the snapshot ( the volume will also be encrypted ) so it has an operational overhead. So assuming they won't use this account for anything else we can use C. Enable EBS encryption by default in the AWS Region where the EKS cluster will be created. Select the customer managed key as the default key.
Comment: "Assuming they won't use this account for anything else" how could we assume that?
Comment: Option D is required wither way. Technically both option B and C would work, but with B you would have to enable encryption node by node, while with option C provides a onetime action of enabling encryption on all nodes. The requirement is the option with LEAST operational overhead.
Comment: B created some deployment work, but NOT "operational (!) overhead" once it's deployed. C enables encryption by default for all new EBS volumes which is not what we want.
Comment: These options allow EBS encryption with the customer managed KMS key with minimal operational overhead: C) Setting the KMS key as the regional EBS encryption default automatically encrypts new EKS node EBS volumes. D) The IAM role grants the EKS nodes access to use the key for encryption/decryption operations.
Comment: C - enable EBS encryption by default in a region -https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html D - Provides key access permission just to the EKS cluster without changing broader IAM permissions
Comment: We're not asked to enable EBS encryption by default.
Comment: I was in doubt between B and C. You can't "Enable EBS encryption by default in the AWS Region". Enable EBS encryption by default is only possible at Account level, not Region. B is the right option once you can enable encryption on the EBS volume with KMS and custom KMS.
Comment: Not accurate: "Encryption by default is a Region-specific setting": https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default
Comment: Still C is wrong because "encryption by default" is not what we want.
Comment: It's C and D. I tried it in my AWS console. C seems to have fewer operations ahead compared to B.
Comment: B and C. Unless the key policy explicitly allows it, you cannot use IAM policies to allow access to a KMS key. Without permission from the key policy, IAM policies that allow permissions have no effect.
Comment: B. Manually enable encryption on the intended EBS volumes after ensuring no default changes. Requires manually enabling encryption on the nodes but ensures minimum impact. D. Create an IAM role with access to the key to associate with the EKS cluster. This provides key access permission just to the EKS cluster without changing broader IAM permissions.
Comment: A. Using a custom plugin requires installing, managing and troubleshooting the plugin. Significant operational overhead. C. Modifying the default region encryption could impact other resources with different needs. Should be avoided if possible. E. Managing Kubernetes secrets for key access requires operations within the EKS cluster. Additional operational complexity.
Comment: Amazon prefers people to move from Oracle to its own services like DynamoDB and S3.
Comment: The company wants a solution that is highly available and scalable
Comment: But DynamoDB is also highly available and scalable https://aws.amazon.com/dynamodb/faqs/#:~:text=DynamoDB%20automatically%20scales%20throughput%20capacity,high%20availability%20and%20data%20durability.
Comment: Yes but has a size limit at 400kb so theoretically it could store images but it's not a plausible solution.
Comment: It doesn't matter the size limit of DynamoDB!!!! The images are saved in S3 buckets. Right answer is B
Comment: but would it be easy and cost-effective to migrate Oracle (relational db) to (Dynamodb)NoSQL?
Comment: Yes because it's a single table with two records, for which Oracle or any relation database has been a bad choice in the first place.
Comment: DynamoDB with its HA and built-in scalability. The nature of the table also resonates with NoSQL than SQL DB such as Oracle. Only 1 table so migration is just a script from Oracle to DynamoDB D is workable but more expensive with Oracle licenses and other setups for HA and scalability
Comment: HA & built-in scalability of Amazon DynamoDB : https://aws.amazon.com/dynamodb/features/#:~:text=Amazon%20DynamoDB%20is%20a%20fully,for%20the%20most%20demanding%20applications.
Comment: A puts images in Oracle, not a good idea C DAX is not going to help with images D It is doable but RDS on multi AZ does not give you more performance or write scalability. It gives more availability and read scalability which is not required here. B works as Geographic code is the key in DynamoDB and S3 image URL is the data so DynamoDB can handle tens of thousands such record and S3 can scale for writing
Comment: They are currently using Oracle, but only for one simple table with a single key-value pair. This is a typical use case for a NoSQL database like DynamoDB (and whoever decided to use Oracle for this in the first place should be fired). Oracle is expensive as hell, so options A and D might work but are surely not cost-effective. C won't work because the images are too big for the database. Leaves B which would be the ideal solution and meet the availability and scalability requirements.
Comment: For D - Oracle is not cheap as well. RDS with Oracle vs DynamoDB, I would go for pure AWS provided option. In each exam there is a lot of marketing => B
Comment: Cost effective, D
Comment: How is Oracle more cost effective than other options?
Comment: B or D, but the question is MOST cost-effectively DynamoDB is more expensive than RDS, I am going for D
Comment: Answer is B, DynamoDB is Highly available and scalable
Comment: A single table in a relational db can have items that are related ? e.g. ‘select * from Faculty where department_id in (10, 20) and dept_name = AWS'. In the sql query example above, * means all and Faculty is name of the table.
Comment: B option offers a cost-effective solution for storing and accessing high-resolution GIS images during natural disasters. Storing the images in Amazon S3 buckets provides scalable and durable storage, while using Amazon DynamoDB allows for quick and efficient retrieval of images based on geographic codes. This solution leverages the strengths of both S3 and DynamoDB to meet the requirements of high availability, scalability, and cost-effectiveness.
Comment: What were the company thinking using the most expensive DB on the planet FOR ONE SINGLE TABLE??? Migrate a single table from SQL to NoSQL should be easy enough I guess...
Comment: Should be D. the question says company wants to migrate oracle to AWS. Oracle is a relational db hence RDS makes more sense whereas Dynamodb is non relational db.
Comment: But relational DB does not make sense for the use case. It's a single table.
Comment: I hate these questions:) I can't choose between B and D
Comment: Guys the answer is B the oracle database only has one table without any relationships so why we should use a relational database in the first place, second we are storing the images in S3 not in the database why not use this alongside dynamo
Comment: You can't do migration of Oracle to Dynmodb without SCT. I am not the DB guy but since its saying oracle I would go with D otherwise B makes more sense if a company is starting out from scratch.
Comment: Actually now that I think about it , B sounds ok as well. Company just need to use SCT and that would be more cost effective.
Comment: "A company wants to migrate an Oracle database to AWS"
Comment: Yeah, per my understanding that doesn't implicate that the destination must be an Oracle database.
Comment: D: Wrorng if you caluate License Oracle Database, It is not cost-effectively. Multi-AZ is not scalable and if you set scalable, you need more license for Oracle database.
Comment: Access patterns is given, therefore D is the most logical answer. Intelligent tiering is for random, unpredictable access.
Comment:
You are missing: <
Comment: I dont get how its A 1. Each morning, the company uses the data from the previous 30 days 2. Four times each year, the company uses the data from the previous 12 months to perform analysis and train other ML models 3. The data must be available with minimal delay for up to 1 year. After 1 year, the data must be retained for archival purposes The data ingestion happens 4 times a year, that means that after the initial 30 days it still needs to be pulled 3 more times, why would you put the data in standard infrequent if you were going to use it 3 more times and speed is a requirement? Makes more sense to put it in S3 standard, or intelligent then straight to glacier.
Comment: Clear access pattern. data in Standard-Infrequent Access is for data requires rapid access when needed
Comment: A and B, Intelligent Tiering cannot be configured. It is managed by AWS. C SIA does not allow immediate access for "each morning" D is best for 30 day standard access, SIA after 30 days and archive after 1 year
Comment: See reasoning below, just accidentally voted A
Comment: The data is used every day (typical use case for Standard) for 30 days, for the remaining 12 months it is used 3 or 4 times (typical use case for IA), after 12 months it is not used at all but must be kept (typical use case for Glacier Deep Archive).
Comment: Sorry, D!!!!!!!!! Not A!!!! D!
Comment: This option optimizes costs while meeting the data access requirements: Store new data in S3 Standard for first 30 days of frequent access Transition to S3 Standard-IA after 30 days for infrequent access up to 1 year Archive to Glacier Deep Archive after 1 year for long-term archival
Comment: First 30 days data accessed every morning = S3 Standard Beyond 30 days data accessed quarterly = S3 Standard-Infrequent Access Beyond 1 year data retained = S3 Glacier Deep Archive
Comment: Option A meets the requirements most cost-effectively. The S3 Intelligent-Tiering storage class provides automatic tiering of objects between the S3 Standard and S3 Standard-Infrequent Access (S3 Standard-IA) tiers based on changing access patterns, which helps optimize costs. The S3 Lifecycle policy can be used to transition objects to S3 Glacier Deep Archive after 1 year for archival purposes. This solution also meets the requirement for minimal delay in accessing data for up to 1 year. Option B is not cost-effective because it does not include the transition of data to S3 Glacier Deep Archive after 1 year. Option C is not the best solution because S3 Standard-IA is not designed for long-term archival purposes and incurs higher storage costs. Option D is also not the most cost-effective solution as it transitions objects to the S3 Standard-IA tier after 30 days, which is unnecessary for the requirement to retrain the suite of ML models each morning using data from the previous 30 days.
Comment: I can't follow. The data is used every day (typical use case for Standard) for 30 days, for the remaining 12 months it is used 3 or 4 times (typical use case for IA), after 12 months it is not used at all but must be kept (typical use case for Glacier Deep Archive).
Comment: Agree with UnluckyDucky , the correct option is D
Comment: Should be D. see this: https://www.examtopics.com/discussions/amazon/view/68947-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Bbbbbbbbb
Comment: hello!!??
Comment: ddddddd
Comment: D because: - First 30 days- data access every morning ( predictable and frequently) – S3 standard - After 30 days, accessed 4 times a year – S3 infrequently access - Data preserved- S3 Gllacier Deep Archive
Comment: AWS Transit Gateway connects your Amazon Virtual Private Clouds (VPCs) and on-premises networks through a central hub. This connection simplifies your network and puts an end to complex peering relationships. Transit Gateway acts as a highly scalable cloud router—each new connection is made only once. https://aws.amazon.com/transit-gateway/#:~:text=AWS-,Transit%20Gateway,-connects%20your%20Amazon
Comment: AWS Direct connect is costly but the saving comes from less data transfer cost with Direct Connect and Transit gateway
Comment: This option leverages a single Direct Connect for consistent, private connectivity between the data center and AWS. The transit gateway allows each VPC to share the Direct Connect while keeping the VPCs isolated. This provides a cost-effective architecture to meet the requirements.
Comment: Transit GW, is a hub for connecting all VPCs. Direct Connect is expensive, therefor only 1 of them connected to the Transit GW (Hub for all our VPCs that we connect to it)
Comment: Option D
Comment: Can someone tell why option C will not work here
Comment: Using multiple Site-to-Site VPNs (A) or Direct Connects (C) incurs higher costs without providing significant benefits.
Comment: cost-effectiveness, 3 DC are more than 1 (more expensive). There is no need to connect more than 1 DC.
Comment: And besides the cost, C does not allow the applications "to communicate between VPCs".
Comment: cost-effectiveness D
Comment: Transit Gateway will achieve this result..
Comment: maximizes cost-effectiveness
Comment: ddddddddd
Comment: AWS Step Functions is a fully managed service that makes it easy to build applications by coordinating the components of distributed applications and microservices using visual workflows. With Step Functions, you can combine multiple AWS Lambda functions into responsive serverless applications and orchestrate data and services that run on Amazon EC2 instances, containers, or on-premises servers. Step Functions also allows for manual approvals as part of the workflow. This solution meets all the requirements with the least operational overhead.
Comment: Approval is explicit for the solution. -> "A common use case for AWS Step Functions is a task that requires human intervention (for example, an approval process). Step Functions makes it easy to coordinate the components of distributed applications as a series of steps in a visual workflow called a state machine. You can quickly build and run state machines to execute the steps of your application in a reliable and scalable fashion. (https://aws.amazon.com/pt/blogs/compute/implementing-serverless-manual-approval-steps-in-aws-step-functions-and-amazon-api-gateway/)"
Comment: involves several serverless functions and AWS services, require manual approvals as part of the workflow, combine the Lambda functions into responsive serverless applications, orchestrate data and services = AWS Step Functions
Comment: AWS Step Functions allow you to easily coordinate multiple Lambda functions and services into serverless workflows with visual workflows. Step Functions are designed for building distributed applications that combine services and require human approval steps. Using Step Functions provides a fully managed orchestration service with minimal operational overhead.
Comment: Serverless && workflow service that need human approval::::step functions
Comment: Key: Distributed Application Processing, Microservices orchestration (Orchestrate Data and Services) A would be the best fit. AWS Step Functions is a visual workflow service that helps developers use AWS services to build distributed applications, automate processes, orchestrate microservices, and create data and machine learning (ML) pipelines. Reference: https://aws.amazon.com/step-functions/#:~:text=AWS%20Step%20Functions%20is%20a,machine%20learning%20(ML)%20pipelines.
Comment: Option A: Use AWS Step Functions to build the application. AWS Step Functions is a serverless workflow service that makes it easy to coordinate distributed applications and microservices using visual workflows. It is an ideal solution for designing architectures for distributed applications that involve multiple AWS services and serverless functions, as it allows us to orchestrate the flow of our application components using visual workflows. AWS Step Functions also integrates with other AWS services like AWS Lambda, Amazon EC2, and Amazon ECS, and it has built-in error handling and retry mechanisms. This option provides a serverless solution with the least operational overhead for building the application.
Comment: database connection rejection errors = RDS Proxy
Comment: RDS Proxy provides a proxy layer that pools and shares database connections to improve scalability. This allows the proxy to handle connection spikes to the database gracefully. Using RDS Proxy requires minimal operational overhead - just create the proxy and reconfigure applications to use it. No code changes needed.
Comment: Wait, why not B?????
Comment: ElastiCache (B) and larger instance type (C) help performance but don't resolve connection issues.
Comment: Amazon ElastiCache tends to have a lower operational overhead compared to Amazon RDS Proxy. BUT we already have " Amazon RDS for MySQL DB instance"
Comment: ElastiCache (B) and larger instance type (C) help performance but don't resolve connection issues.
Comment: To reduce application failures resulting from database connection timeouts, the best solution is to enable RDS Proxy on the RDS DB instances
Comment: Many applications, including those built on modern serverless architectures, can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability. (https://aws.amazon.com/pt/rds/proxy/)
Comment: The correct solution for this scenario would be to create a proxy in RDS Proxy. RDS Proxy allows for managing thousands of concurrent database connections, which can help reduce connection errors. RDS Proxy also provides features such as connection pooling, read/write splitting, and retries. This solution requires the least operational overhead as it does not involve migrating to a different instance class or setting up a new cache layer. Therefore, option A is the correct answer.
Comment: The most efficient solution for this scenario is to use EC2 Auto Scaling lifecycle hooks to run a custom script to send data to the audit system when instances are launched and terminated. The lifecycle hook can be used to delay instance termination until the script has completed, ensuring that all data is sent to the audit system before the instance is terminated. This solution is more efficient than using a scheduled AWS Lambda function, which would require running the function periodically and may not capture all instances launched and terminated within the interval. Running a custom script through user data is also not an optimal solution, as it may not guarantee that all instances send data to the audit system. Therefore, option B is the correct answer.
Comment: Use EC2 Auto Scaling lifecycle hooks to run a custom script to send data to the audit system when instances are launched and terminated
Comment: EC2 Auto Scaling lifecycle hooks allow you to perform custom actions as instances launch and terminate. This is the most efficient way to trigger the auditing script execution at instance launch and termination.
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
Comment: Amazon EC2 Auto Scaling offers the ability to add lifecycle hooks to your Auto Scaling groups. These hooks let you create solutions that are aware of events in the Auto Scaling instance lifecycle, and then perform a custom action on instances when the corresponding lifecycle event occurs. (https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
Comment: it is B. read this: https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
Comment: UDP = NLB Non-relational data = Dynamo DB
Comment: key words - UDP, non-relational data answers - NLB for UDP application, DynamoDB for non-relational data
Comment: This option provides the most scalable and optimized architecture for the real-time multiplayer game: Network Load Balancer efficiently distributes UDP gaming traffic to the Auto Scaling group of game servers. DynamoDB On-Demand mode provides auto-scaling non-relational data storage for gamer scores and other game data. DynamoDB is optimized for fast, high-scale access patterns seen in gaming. Together, the Network Load Balancer and DynamoDB On-Demand provide an architecture that can smoothly scale up and down to match spikes in gaming demand.
Comment: Option B is a good fit because a Network Load Balancer can handle UDP traffic, and Amazon DynamoDB on-demand can provide automatic scaling without intervention
Comment: Correct option is “B”
Comment: B https://www.examtopics.com/discussions/amazon/view/29756-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: B Because NLB can handle UDP and DynamoDB is Non-Relational
Comment: Key: the Lambda function loads many libraries Configuring provisioned concurrency would get rid of the "cold start" of the function therefore speeding up the proccess.
Comment: Provisioned concurrency – Provisioned concurrency initializes a requested number of execution environments so that they are prepared to respond immediately to your function's invocations. Note that configuring provisioned concurrency incurs charges to your AWS account.
Comment: Provisioned concurrency pre-initializes execution environments which are prepared to respond immediately to incoming function requests.
Comment: Provisioned concurrency ensures a configured number of execution environments are ready to serve requests to the Lambda function. This avoids cold starts where the function would otherwise need to load all the libraries on each invocation.
Comment: Provisioned concurrency ensures a configured number of execution environments are ready to serve requests to the Lambda function. This avoids cold starts where the function would otherwise need to load all the libraries on each invocation.
Comment: Answer B is correct https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html Answer C: need to modify the application
Comment: This is relevant to "cold start" with keywords: "Lambda function loads many libraries"
Comment: https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html
Comment: The most efficient solution for automatically starting and stopping EC2 instances and DB instances on a schedule while minimizing cost and infrastructure maintenance is to create an AWS Lambda function and configure Amazon EventBridge to invoke the function on a schedule. Option A, scaling EC2 instances by using elastic resize and scaling DB instances to zero outside of business hours, is not feasible as DB instances cannot be scaled to zero. Option B, exploring AWS Marketplace for partner solutions, may be an option, but it may not be the most efficient solution and could potentially add additional costs. Option C, launching another EC2 instance and configuring a crontab schedule to run shell scripts that will start and stop the existing EC2 instances and DB instances on a schedule, adds unnecessary infrastructure and maintenance.
Comment: This option leverages AWS Lambda and EventBridge to automatically schedule the starting and stopping of resources. Lambda provides the script/code to stop/start instances without managing servers. EventBridge triggers the Lambda on a schedule without cronjobs. No additional code or third party tools needed. Serverless, maintenance-free solution
Comment: its d but nowadays u use system manager me thinks
Comment: Create an AWS Lambda function that will start and stop the EC2 instances and DB instances. Configure Amazon EventBridge to invoke the Lambda function on a schedule.
Comment: Minimize cost and maintenance...
Comment: DDDDDDDDDDD
Comment: The key reasons are: Aurora PostgreSQL provides native PostgreSQL compatibility, so minimal code changes would be required. Using an Aurora Replica separates the reporting workload from the main workload, preventing any slowdown of document updates/inserts. Aurora can auto-scale read replicas to handle the reporting load. This allows leveraging the existing PostgreSQL database without major changes. DynamoDB would require more significant rewrite of data access code. RDS Multi-AZ alone would not fully separate the workloads, as the secondary is for HA/failover more than scaling read workloads.
Comment: Load balancing = Read replica High availability = Multi AZ
Comment: No Modifications allowerd = Read Replica
Comment: How in the bloody hell it's D?????
Comment: B is correct
Comment: We also have a requirement for the Least amount of change to the code. Since our DB is PostgreSQL, A & D are immediately out. Multi-AZ won't help with offloading read requests, hence the answer is B ;)
Comment: It is B
Comment: D. Reporting process Must not prevent = allow modification and addition of new document. all read replica were wrong.
Comment: How would 'issuing queries to the read replica' prevent modifications or updates?
Comment: Why not A? :(
Comment: "The reporting process takes a few hours with the use of RELATIONAL queries."
Comment: DocumentDB (For MongoDB) is no SQL. DynamoDB is also No SQL. Therefore, options A and D are out.
Comment: B is the right one. why admin does not correct these wrong answers?
Comment: The reporting process queries the metadata (not the documents) and use relational queries-> A, D out C: wrong since secondary RDS node in MultiAZ setup is in standby mode, not available for querying B: reporting using a Replica is a design pattern. Using Aurora is an exam pattern.
Comment: B is right..
Comment: While both B&D seems to be a relevant, ChatGPT suggest B as a correct one
Comment: Option B (Set up a new Amazon Aurora PostgreSQL DB cluster that includes an Aurora Replica. Issue queries to the Aurora Replica to generate the reports) is the best option for speeding up the reporting process for a three-tier web application that includes a PostgreSQL database storing metadata from documents, while not impacting document modifications or additions, with the least amount of change to the application code.
Comment: "LEAST amount of change to the application code" Aurora is a relational database, it supports PostgreSQL and with the help of read replicas we can issue the reporting proccess that take several hours to the replica, therefore not affecting the primary node which can handle new writes or document modifications.
Comment: its D only ,recorrected
Comment: DynamoDB is no SQL. A and D are out!
Comment: bbbbbbbb
Comment: Network Load Balancers now support TLS protocol. With this launch, you can now offload resource intensive decryption/encryption from your application servers to a high throughput, and low latency Network Load Balancer. Network Load Balancer is now able to terminate TLS traffic and set up connections with your targets either over TCP or TLS protocol. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html https://exampleloadbalancer.com/nlbtls_demo.html
Comment: security of data in transit -> think of SSL/TLS. Check: NLB supports TLS https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html B (DDoS), C (SQL Injection), D (EBS) is for data at rest.
Comment: secure data in transit = TLS
Comment: TLS provides encryption for data in motion over the network, protecting against eavesdropping and tampering. A valid server certificate signed by a trusted CA will provide further security.
Comment: To improve the security of data in transit, you can configure a TLS listener on the Network Load Balancer (NLB) and deploy the server certificate on it. This will encrypt traffic between clients and the NLB. You can also use AWS Certificate Manager (ACM) to provision, manage, and deploy SSL/TLS certificates for use with AWS services and your internal connected resources1. You can also change the load balancer to an Application Load Balancer (ALB) and enable AWS WAF on it. AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources3. the A and C correct without transit but the need to improve the security of the data in transit? so he need SSL/TLS certificates
Comment: agree with fruto123
Comment: "predictable capacity and uptime requirements" means "Reserved" "sockets and cores" means "dedicated host"
Comment: Bring custom purchased licenses to AWS -> Dedicated Host -> C,D out Need cost effective solution -> "reserved" -> A
Comment: https://aws.amazon.com/ec2/dedicated-hosts/ Amazon EC2 Dedicated Hosts allow you to use your eligible software licenses from vendors such as Microsoft and Oracle on Amazon EC2, so that you get the flexibility and cost effectiveness of using your own licenses, but with the resiliency, simplicity and elasticity of AWS.
Comment: BYOL >>> Dedicated Hosts
Comment: A. Dedicated Reserved Hosts Here's why: License Flexibility: Dedicated Reserved Hosts allow the company to bring their existing licenses to AWS. This option enables them to continue using their purchased licenses without any additional cost or licensing changes. Cost Optimization: Reserved Hosts offer significant cost savings compared to On-Demand pricing. By purchasing Reserved Hosts, the company can benefit from discounted hourly rates for the entire term of the reservation, which typically spans one or three years.
Comment: I work with COTS applications they require a three tier architecture, its completely irrelevant and confusing to add that to the question, the key word here is licenses, since AWS wants your to use their solutions the answer to this is which of one the options solves this particular problem, in this case its dedicated hosts.
Comment: What is difference between dedicated host and reserved instance? Dedicated Instance: The physical machine or underlying hardware is reserved for use for the whole account. You can have instances for different purposes on this hardware. Dedicated Host: The physical machine or the underlying hardware is reserved for "Single Use" only, eg. a certain application.
Comment: What is the difference between a dedicated instance and a dedicated host tenancy? Dedicated Instance ( dedicated ) — Your instance runs on single-tenant hardware. Dedicated Host ( host ) — Your instance runs on a physical server with EC2 instance capacity fully dedicated to your use, an isolated server with configurations that you can control.
Comment: Actually the question is a bit ambiguous because there ARE "software licensing model using sockets and cores" that accept virtual sockets are cores as the base, for which C would work. But most of these license models are based on PHYSICAL sockets, thus A.
Comment: Dedicated Hosts give you visibility and control over how instances are placed on a physical server and also enable you to use your existing server-bound software licenses like Windows Server
Comment: Easy with one, but only 79% up to now answered correctly. It is A. Reserved because of the predictable and sockets and cores means dedicated host.
Comment: The correct answer is C. Dedicated Reserved Instances. Dedicated Reserved Instances (DRIs) are the most cost-effective option for workloads that have predictable capacity and uptime requirements. DRIs offer a significant discount over On-Demand Instances, and they can be used to lock in a price for a period of time. In this case, the company has predictable capacity and uptime requirements because the software has a software licensing model using sockets and cores. The company also wants to use its existing licenses, which were purchased earlier this year. Therefore, DRIs are the most cost-effective option.
Comment: I don't agree with people voting "A". The question reference that the COTS Application has a licensing model based on "sockets and cores". The question does not specify if it means TCP sockets (= open connections) or hardware sockets, so I assume that "TCP sockets are intended". If this is the case, sockets and cores can also remain stable with reserved instances - which are cheaper than reserved hosts. I would go with "A" only if the question would clearly state that the COTS application has some strong dependency on physiscal hardware.
Comment: note: instead, if by socket we mean "CPU sockets", then A would be the right one.
Comment: Even if "sockets" mean TCP sockets there are still the cores, thus A
Comment: A https://www.examtopics.com/discussions/amazon/view/35818-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Dedicated Host Reservations provide a billing discount compared to running On-Demand Dedicated Hosts. Reservations are available in three payment options. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html
Comment: A is the most cost effective
Comment: Multi AZ = both EFS and S3 support Storage classes = both EFS and S3 support POSIX file system access = only Amazon EFS supports
Comment: POSIX => EFS https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html
Comment: Answer:B cause there is no life cycle policy for EFS that will work in S3 only.
Comment: "storage layer will be accessed frequently for the first 30 days and will be accessed infrequently after that time" Was the only reason they added this to trick you?
Comment: POSIX -> EFS, "maximum data durability" rules out One Zone
Comment: Both standard and one zone have same durability. https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html Also EFS one zone can work with multiple EC2s in different AZs. But there will be a cost involved when you are accessing the EFS from a different AZ EC2. (EC2 data access charges) https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html So if "all" EC2 instances accessing the files frequently there will be a storage cost + EC2 data access charges if you choose one zone. So i would choose C.
Comment: Ans: C
Comment: Ans: D, one-zone IA for ‘most cost effective' . https://aws.amazon.com/efs/features/infrequent-access/
Comment: How does D fulfill the data durability requirement? Requirements must be met first, then consider 'most cost effective' - if you go to a tire shop, and say you want 4 new tires as cheap as possible. And they take off 4 tires and put on 2... Then they say you wanted it as cheap as possible...
Comment: What about “ The application needs a storage layer that is highly available” and “application on Amazon EC2 Linux instances across multiple Availability Zones ” ?
Comment: Use the Amazon Elastic File System (Amazon EFS) Standard storage class. Create a lifecycle management policy to move infrequently accessed data to EFS Standard-Infrequent Access (EFS Standard-IA).
Comment: Amazon Elastic File System (Amazon EFS) Standard storage class = "maximum data durability"
Comment: "ONE ZONE-IA" does not meet the "maximum data durability" requirement
Comment: D - It should be cost-effective
Comment: But D does meet the durability requirement.
Comment: POSIX file system access = only Amazon EFS supports
Comment: POSIX + sharable across EC2 instances --> EFS --> A, B out Instances run across multiple AZ -> C is needed.
Comment: Linux based system points to EFS plus POSIX-compliant is also EFS related.
Comment: "POSIX-compliant" means EFS. also, file system can be shared with multiple EC2 instances means "EFS"
Comment: Option C is the correct answer .
Comment: Answer c : https://aws.amazon.com/efs/features/infrequent-access/
Comment: Option C aligns with the least access principle and provides a clear and granular control over the communication between different components in the architecture. Option D suggests using network ACLs, but security groups are more suitable for controlling access to individual instances based on their security group membership, which is why Option C is the more appropriate choice in this contex
Comment: Create a security group for the web servers and allow port 443 from the load balancer. Create a security group for the MySQL servers and allow port 3306 from the web servers security group.
Comment: C) Create a security group for the web servers and allow port 443 from the load balancer. Create a security group for the MySQL servers and allow port 3306 from the web servers security group. This option follows the principle of least privilege by only allowing necessary access: Web server SG allows port 443 from load balancer SG (not open to world) MySQL SG allows port 3306 only from web server SG
Comment: Create a security group for the web servers and allow port 443 from the load balancer. Create a security group for the MySQL servers and allow port 3306 from the web servers security group
Comment: Option C is the correct choice.
Comment: Load balancer is public facing accepting all traffic coming towards the VPC (0.0.0.0/0). The web server needs to trust traffic originating from the ALB. The DB will only trust traffic originating from the Web server on port 3306 for Mysql
Comment: Just C. plain and simple
Comment: C https://www.examtopics.com/discussions/amazon/view/43796-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: cccccc
Comment: the best solution is to implement Amazon ElastiCache to cache the large datasets, which will store the frequently accessed data in memory, allowing for faster retrieval times. This can help to alleviate the frequent calls to the database, reduce latency, and improve the overall performance of the backend tier.
Comment: Answer is B This will help reduce the frequency of calls to the database and improve overall performance by serving frequently accessed data from the cache instead of fetching it from the database every time. It's is not option C as it suggests implementing an RDS for MySQL read replica to cache database calls. While read replicas can offload read operations from the primary database instance and improve read scalability, they are primarily used for read scaling and high availability rather than caching. Read replicas are intended to handle read-heavy workloads by distributing read requests across multiple instances. However, they do not inherently cache data like ElastiCache does.
Comment: Answer is B This will help reduce the frequency of calls to the database and improve overall performance by serving frequently accessed data from the cache instead of fetching it from the database every time. It's is not option C as it suggests implementing an RDS for MySQL read replica to cache database calls. While read replicas can offload read operations from the primary database instance and improve read scalability, they are primarily used for read scaling and high availability rather than caching. Read replicas are intended to handle read-heavy workloads by distributing read requests across multiple instances. However, they do not inherently cache data like ElastiCache does.
Comment: Keyword is identical datasets
Comment: As per Amazon Q: ElastiCache can be used to cache datasets from queries to RDS databases. Some key points: While creating an ElastiCache cluster from the RDS console provides convenience, the application is still responsible for leveraging the cache. Caching query results in ElastiCache can significantly improve performance by allowing high-volume read operations to be served from cache versus hitting the database. This is especially useful for applications with high read throughput needs, as scaling the database can become more expensive compared to scaling the cache as needs increase. ElastiCache nodes can support up to 400,000 queries per second. Cost savings are directly proportional to read throughput - higher throughput applications see greater savings.
Comment: The best scenario to implement caching, identical calls to the same data sets.
Comment: B) Implement Amazon ElastiCache to cache the large datasets. The key issue is repeated calls to return identical datasets from the RDS database causing performance slowdowns. Implementing Amazon ElastiCache for Redis or Memcached would allow these repeated query results to be cached, improving backend performance by reducing load on the database.
Comment: B) Implement Amazon ElastiCache to cache the large datasets. The key issue is repeated calls to return identical datasets from the RDS database causing performance slowdowns. Implementing Amazon ElastiCache for Redis or Memcached would allow these repeated query results to be cached, improving backend performance by reducing load on the database.
Comment: Thanks Tariq for the simplified answer below: frequent identical calls = ElastiCache
Comment: frequent identical calls = ElastiCache
Comment: Tricky question, anyway.
Comment: Yes, cashing is the solution but is Elasticache compatible with RDS MySQL DB? So, what about the answer C with a DB read replica? For me it's C.
Comment: B https://www.examtopics.com/discussions/amazon/view/27874-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Key term is identical datasets from the database it means caching can solve this issue by cached in frequently used dataset from DB
Comment: The answers inside the question: CloudFormation. A is exlucded since root account is never a choice for the principle of least privilege. D, E left are the correct ones.
Comment: ABC are just giving too much access so CD are logical choices
Comment: Create a new IAM user for the deployment engineer and add the IAM user to a group that has an IAM policy that allows AWS CloudFormation actions only. Create an IAM role for the deployment engineer to explicitly define the permissions specific to the AWS CloudFormation stack and launch stacks using that IAM role.
Comment: The two actions that should be taken to follow the principle of least privilege are: D) Create a new IAM user for the deployment engineer and add the IAM user to a group that has an IAM policy that allows AWS CloudFormation actions only. E) Create an IAM role for the deployment engineer to explicitly define the permissions specific to the AWS CloudFormation stack and launch stacks using that IAM role. The principle of least privilege states that users should only be given the minimal permissions necessary to perform their job function.
Comment: Option D, creating a new IAM user and adding them to a group with an IAM policy that allows AWS CloudFormation actions only, ensures that the deployment engineer has the necessary permissions to perform AWS CloudFormation operations while limiting access to other resources and actions. This aligns with the principle of least privilege by providing the minimum required permissions for their job activities. Option E, creating an IAM role with specific permissions for AWS CloudFormation stack operations and allowing the deployment engineer to assume that role, is another valid approach. By using an IAM role, the deployment engineer can assume the role when necessary, granting them temporary permissions to perform CloudFormation actions. This provides a level of separation and limits the permissions granted to the engineer to only the required CloudFormation operations.
Comment: Dddd,Eeee
Comment: D & E are a good choices
Comment: D, E https://www.examtopics.com/discussions/amazon/view/46428-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: thank you my friend
Comment: I agree DE
Comment: Security group defaults block all inbound traffic..Add an inbound rule to the security group of the database tier's RDS instance to allow traffic from the web tiers security group
Comment: For those questioning why the answer is not A: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html Default NACLs allow all traffic, and in this question NACLs, SGs and route tables are in their default states.
Comment: I think the answer should be A. Sine the services are in different subnets, the NACL would by default block all the incoming traffic to the subnet. Security group rule wouldn't be able to override NACL rule.
Comment: I selected option D as well, but I have a question regarding option A. Considering that the EC2 instances and the RDS are located in different subnets, shouldn't the network ACLs for each subnet allow traffic from one another as well? Given that the default settings for network ACLs typically block all traffic, wouldn't it be necessary to explicitly permit communication between the subnets?
Comment: Security Groups are tied on instance where as network ACL are tied to Subnet.
Comment: By default, all inbound traffic to an RDS instance is blocked. Therefore, an inbound rule needs to be added to the security group of the RDS instance to allow traffic from the security group of the web tier's EC2 instances.
Comment: D is the correct answer
Comment: D https://www.examtopics.com/discussions/amazon/view/81445-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: D is correct option
Comment: ddddddd
Comment: reporting queries to run without impacting the write operations -> read replicas
Comment: A) Deploy RDS read replicas to process the business reporting queries. The key points are: RDS read replicas allow read-only copies of the production DB instance to be created Queries to the read replica don't affect the source DB instance performance This isolates reporting queries from production traffic and write operations So using RDS read replicas is the best way to meet the requirements of running reporting queries without impacting production write operations.
Comment: "single AZ", "large dataset", "Amazon RDS for MySQL database". Want "business report queries". --> Solution "Read replicas", choose A.
Comment: No doubt A.
Comment: Load balance read operations = read replicas
Comment: reports=read replica
Comment: Option "A" is the right answer . Read replica use cases - You have a production database that is taking on normal load & You want to run a reporting application to run some analytics • You create a Read Replica to run the new workload there • The production application is unaffected • Read replicas are used for SELECT (=read) only kind of statements (not INSERT, UPDATE, DELETE)
Comment: aaaaaaaaaaa
Comment: option A is the best solution for ensuring that business reporting queries can run without impacting write operations to the production DB instance.
Comment: It is A and D. Proof is in link below. https://aws.amazon.com/caching/session-management/
Comment: This doesn't say anything about durability
Comment: I did not get why A is most voted? The question did not mention anything about fixed routing target so the ALB should route traffic randomly to each server. Then we just need to provide cache session management to avoid session lost issue instead of using sticky session.
Comment: Option A suggests using sticky sessions (session affinity) on the Application Load Balancer (ALB). While sticky sessions can help route requests from the same client to the same backend server, it doesn't directly address the requirement for durable storage of session data. Sticky sessions are typically used to maintain session state at the load balancer level, but they do not provide data durability in case of server failures or restarts. Option A - is not correct ! ! ! So answer is option B and D ! ! !
Comment: why does it matter to store user sessions durably? they EXPIRE, why would a company care about storing user sessions, thats not something thats done in the real world, those things are usually data dumped, or overwritten with new session tokens LOL, this whole question is &^%&*^$#@%^
Comment: I think the question is intended to mean "Combination of services", as some answers say "to store" or "to manage". So i am going for A+B, as sticky sessions are intended to manage the sessions and DynamoDB to store durably.
Comment: Going for AB. Sticky Sessions to "optimize customer session management during transactions" and DynamoDB to "store session data durably". D, ElastiCache does NOT allow "durable" storage. Just because there's an article that contains both words "ElastiCache" and "durable" does not prove the contrary. C and E, Cognito and Systems Manager, have nothing to do with the issue.
Comment: I agree that ElastiCache for Redis is not a durable KV store. But what about the phrasing? "Which solutions will meet these requirements? (Choose two.)" Solutions (plural) implies two ways to *independently* fulfill the requirements. If you're supposed to select a combination of options, it's usually phrased like this: "Which combination of solutions ..."
Comment: https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/ Amazon ElastiCache for Redis is highly suited as a session store to manage session information such as user authentication tokens, session state, and more. Simply use ElastiCache for Redis as a fast key-value store with appropriate TTL on session keys to manage your session information. Session management is commonly required for online applications, including games, e-commerce websites, and social media platforms.
Comment: Correct link: https://aws.amazon.com/elasticache/redis/
Comment: I don't understand what Sticky Session has to do with session storage. For the intent of the problem, I think DynamoDB and Redis are appropriate.
Comment: "Session storage" is not the only requirement here. It is about 'optimizing customer session management during transactions', obviously it makes sense to host customer sessions on same node to easy the session management.
Comment: Chatgpt4 says B and D Option A (Sticky sessions) is more for ensuring that a client's requests are sent to the same target once a session is established, but it doesn't provide a mechanism for durable session data storage across multiple instances. Option C (Amazon Cognito) is more for user identity management rather than session data storage during transactions. Option E (AWS Systems Manager Application Manager) is not a suitable or standard choice for session management in applications.
Comment: Answers starting with "ChatGPT says ..." are usually wrong. In that case, B and D solve the same part of the requirement (storing session data), just B is durable (as required) while D is not durable (thus failing to meet the requirement). We still need to 'optimize customer session management'.
Comment: Well, this documentation says it all. Option A is obvious, and D ElastiCache for Redis, can even support replication in case of node failure/session data loss. https://aws.amazon.com/caching/session-management/
Comment: ElastiCache can be HA and supports replication, but it remains a cache, which is by definition not durable.
Comment: It is A and D. Proof is in link below. https://aws.amazon.com/caching/session-management/
Comment: That does not say anything about durability.
Comment: cache is not durable...at all
Comment: go for AD
Comment: go with B
Comment: For D : "Amazon ElastiCache for Redis is highly suited as a session store to manage session information such as user authentication tokens, session state, and more." https://aws.amazon.com/elasticache/redis/
Comment: Elsewhere they state: "Redis was not built to be a durable and consistent database. If you need a durable, Redis-compatible database, consider Amazon MemoryDB for Redis. Because MemoryDB uses a durable transactional log that stores data across multiple Availability Zones (AZs), you can use it as your primary database. MemoryDB is purpose-built to enable developers to use the Redis API without worrying about managing a separate cache, database, or the underlying infrastructure." https://aws.amazon.com/redis/
Comment: What about durability?
Comment: B and D: "The application must store session data durably" with Sticky sessions the application doesn't store anything.
Comment: Why would sticky sessions stop applicaton from storing anything?
Comment: An option for data persistence for ElastiCache: https://aws.amazon.com/elasticache/faqs/#:~:text=Q%3A%20Does%20Amazon%20ElastiCache%20for%20Redis%20support%20Redis%20persistence%3F%0AAmazon%20ElastiCache%20for%20Redis%20doesn%E2%80%99t%20support%20the%20AOF%20(Append%20Only%20File)%20feature%20but%20you%20can%20achieve%20persistence%20by%20snapshotting%20your%20Redis%20data%20using%20the%20Backup%20and%20Restore%20feature.%20Please%20see%20here%20for%20details.
Comment: The opposite is true: "ElastiCache is ideally suited as a front end for AWS services like Amazon RDS and DynamoDB, providing extremely low latency for high-performance applications and offloading some of the request volume while these services (!!!) provide long-lasting data durability." ElastiCache can serve as a cache for DynamoDB and provide low latency while DynamoDB (!) provides durability.
Comment: ElastiCache is not durable so session info has to be stored in DynamoDB.
Comment: that if there is no temporary local storage on the EC2 instances, then snapshots of EBS volumes are not necessary. Therefore, if your application does not require temporary storage on EC2 instances, using AMIs to back up the web and application tiers is sufficient to restore the system after a failure. Snapshots of EBS volumes would be necessary if you want to back up the entire EC2 instance, including any applications and temporary data stored on the EBS volumes attached to the instances. When you take a snapshot of an EBS volume, it backs up the entire contents of that volume. This ensures that you can restore the entire EC2 instance to a specific point in time more quickly. However, if there is no temporary data stored on the EBS volumes, then snapshots of EBS volumes are not necessary.
Comment: I think "temporal local storage" refers to "instance store", no instance store is required. EBS is durable storage, not temporal.
Comment: Look at the first paragraph. https://repost.aws/knowledge-center/instance-store-vs-ebs
Comment: Considering it's a "stateless web application", that would still be no reason to back up the EBS volumes.
Comment: The web application does not require temporary local storage on the EC2 instances => No EBS snapshot is required, retaining the latest AMI is enough.
Comment: The web application does not require temporary local storage on the EC2 instances so we do not care about ECS. We only need two things here , the image of the instance (AMI) and a database backup. C
Comment: "The web application does not require temporary local storage on the EC2 instances" rules out any option to back up the EC2 EBS volumes.
Comment: Question says: ...stateless web application.. that means application doesn't store any data, so no EBS required
Comment: Since the application has no local data on instances, AMIs alone can meet the RPO by restoring instances from the most recent AMI backup. When combined with automated RDS backups for the database, this provides a complete backup solution for this environment. The other options involving EBS snapshots would be unnecessary given the stateless nature of the instances. AMIs provide all the backup needed for the app tier. This uses native, automated AWS backup features that require minimal ongoing management: - AMI automated backups provide point-in-time recovery for the stateless app tier. - RDS automated backups provide point-in-time recovery for the database.
Comment: BBBBBBBBBB
Comment: Why back up EBS volumes of the autoscaled instances?
Comment: I vote for D
Comment: Why back up EBS volumes of the autoscaled instances?
Comment: makes more sense.
Comment: Answer is C. Keyword to notice "Stateless"
Comment: why B? I mean "stateless" and "does not require temporary local storage" have indicate that we don't need to take snapshot for ec2 volume.
Comment: Option B is the most appropriate solution for the given requirements. With this solution, a snapshot lifecycle policy can be created to take Amazon Elastic Block Store (Amazon EBS) snapshots periodically, which will ensure that EC2 instances can be restored in the event of an outage. Additionally, automated backups can be enabled in Amazon RDS for PostgreSQL to take frequent backups of the database tier. This will help to minimize the RPO to 2 hours. Taking snapshots of Amazon EBS volumes of the EC2 instances and database every 2 hours (Option A) may not be cost-effective and efficient, as this approach would require taking regular backups of all the instances and volumes, regardless of whether any changes have occurred or not. Retaining the latest Amazon Machine Images (AMIs) of the web and application tiers (Option C) would provide only an image backup and not a data backup, which is required for the database tier. Taking snapshots of Amazon EBS volumes of the EC2 instances every 2 hours and enabling automated backups in Amazon RDS and using point-in-time recovery (Option D) would result in higher costs and may not be necessary to meet the RPO requirement of 2 hours.
Comment: Why back up EBS volumes of the autoscaled instances? "Retaining the latest Amazon Machine Images (AMIs) of the web and application tiers (Option C) would provide only an image backup and not a data backup, which is required for the database tier." False because option C also includes "automated backups in Amazon RDS".
Comment: B. Configure a snapshot lifecycle policy to take Amazon Elastic Block Store (Amazon EBS) snapshots. Enable automated backups in Amazon RDS to meet the RPO. The best solution is to configure a snapshot lifecycle policy to take Amazon Elastic Block Store (Amazon EBS) snapshots, and enable automated backups in Amazon RDS to meet the RPO. An RPO of 2 hours means that the company needs to ensure that the backup is taken every 2 hours to minimize data loss in case of a disaster. Using a snapshot lifecycle policy to take Amazon EBS snapshots will ensure that the web and application tier can be restored quickly and efficiently in case of a disaster. Additionally, enabling automated backups in Amazon RDS will ensure that the database tier can be restored quickly and efficiently in case of a disaster. This solution maximizes scalability and optimizes resource utilization because it uses automated backup solutions built into AWS.
Comment: No need to back up the EBS volumes of autoscaled instances.
Comment: "The application must be secure and accessible for global customers that have dynamic IP addresses." This just means "anyone" so BC are wrong as you cannot know in advance about the dynamic IP addresses. D is just opening the DB to the internet. A is most secure as web is open to internet and db is open to web only.
Comment: The keyword is dynamic IPs from the customer, then B, C out, D out due to 0.0.0.0/0
Comment: It allows HTTPS access from any public IP address, meeting the requirement for global customer access. HTTPS provides encryption for secure communication. And for the database security group, only allowing inbound port 3306 from the web server security group properly restricts access to only the resources that need it.
Comment: Should be A since the customer IPs are dynamically.
Comment: A no doubt.
Comment: BBBBBBBBBBBBBBBBBBBBBB from customers IPs
Comment: Correct answer A, customer dynamic IPs ==>> 443 from 0.0.0.0/0
Comment: dynamic source ips = allow all traffic - Configure the security group for the web servers to allow inbound traffic on port 443 from 0.0.0.0/0. Configure the security group for the DB instance to allow inbound traffic on port 3306 from the security group of the web servers.
Comment: If the customers have dynamic IP addresses, option A would be the most appropriate solution for allowing global access while maintaining security.
Comment: Correct answer is A. B and C are out. D is out because it is accepting traffic from every where instead of from webservers only
Comment: A is correct
Comment: Keyword dynamic ...A is the right answer. If the IP were static and specific, B would be the right answer
Comment: Then why voted B?
Comment: aaaaaaa
Comment: Ans - A
Comment: aaaaaa
Comment: speech to text = Amazon Transcribe
Comment: Amazon Transcribe is a service provided by Amazon Web Services (AWS) that converts speech to text using automatic speech recognition (ASR) technology
Comment: AWS Transcribe https://aws.amazon.com/transcribe/ . Redacting or identifying (Personally identifiable instance) PII in real-time stream https://docs.aws.amazon.com/transcribe/latest/dg/pii-redaction-stream.html .
Comment: C Amazon Transcribe is a service provided by Amazon Web Services (AWS) that converts speech to text using automatic speech recognition (ASR) technology. gtp
Comment: Option C is the most suitable solution as it suggests using Amazon Transcribe with PII redaction turned on. When an audio file is uploaded to the S3 bucket, an AWS Lambda function can be used to start the transcription job. The output can be stored in a separate S3 bucket to ensure that the PII redaction is applied to the transcript. Amazon Transcribe can redact PII such as credit card numbers, social security numbers, and phone numbers.
Comment: C for sure.....
Comment: C for sure
Comment: ccccccccc
Comment: answer c
Comment: Option C is correct..
Comment: A - Magnetic Max IOPS 200 - Wrong B - gp3 Max IOPS 16000 per volume - Wrong C - RDS not supported io2 - Wrong D - Correct; 2 gp3 volume with 16 000 each 2*16000 = 32 000 IOPS
Comment: I really wonder how this answer can be the top answer. How would it even be possible to provision multiple gp3 volumes for RDS? RDS manages the storage, we have no influence on the number of volumes. *Striping* is something that RDS does automatically depending on storage class and volume size: "When you select General Purpose SSD or Provisioned IOPS SSD, depending on the engine selected and the amount of storage requested, Amazon RDS automatically stripes across multiple volumes to enhance performance (...)" For MariaDB with 400 to 64,000 GiB of gp3 storage, RDS automatically provisions 4 volumes. This gives us 12,000 IOPS *baseline* and can be increased up to 64,000 *provisioned* IOPS. RDS does not support io2. Therefore: Option B
Comment: PS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: It must be that io2 was originally not supported by RDS, because I see this untruth reposted everywhere. It totally is.
Comment: https://repost.aws/knowledge-center/ebs-volume-type-differences RDS does support io2
Comment: that Link is to EBS instead of RDS
Comment: ‘the application performance always degrades when the number of read and write IOPS is higher than 20,000' … question didn't say read and write IOPs can't be higher than 32,000. Answer: C if it's based on performance and not cost related. ‘Amazon RDS provides three storage types: General Purpose SSD (also known as gp2 and gp3), Provisioned IOPS SSD (also known as io1), and magnetic (also known as standard). They differ in performance characteristics and price, which means that you can tailor your storage performance and cost to the needs of your database workload.' https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: It can not be option C as RDS does not support io2 storage type (only io1). Here is a link to the RDS storage documentation: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html Also it is not the best option to take Magnetic storage as it supports max 1000 IOPS. I vote for option B as gp3 storage type supports up to 64 000 IOPS where question mentioned with problem at level of 20 000.
Comment: check the link below https://repost.aws/knowledge-center/ebs-volume-type-differences it states: General Purpose SSD volumes are good for a wide variety of transactional workloads that require less than the following: 16,000 IOPS 1,000 MiB/s of throughput 160-TiB volume size
Comment: is this true? Amazon RDS (Relational Database Service) supports the Provisioned IOPS SSD (io2) storage type for its database instances. The io2 storage type is designed to deliver predictable performance for critical and highly demanding database workloads. It provides higher durability, higher IOPS, and lower latency compared to other Amazon EBS (Elastic Block Store) storage types. RDS offers the option to choose between the General Purpose SSD (gp3) and Provisioned IOPS SSD (io2) storage types for database instances.
Comment: Please add a reference where it states that io2 is supported by RDS.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html - Right there in the first paragraph: "Amazon RDS provides three storage types: General Purpose SSD (also known as gp2 and gp3), Provisioned IOPS SSD (also known as io1 and io2 Block Express), and magnetic (also known as standard). They differ in performance characteristics and price, which means that you can tailor your storage performance and cost to the needs of your database workload. You can create Db2, MySQL, MariaDB, Oracle, and PostgreSQL RDS DB instances with up to 64 tebibytes (TiB) of storage. "
Comment: Answer is C, io2 volumes are supported https://aws.amazon.com/blogs/aws/amazon-rds-now-supports-io2-block-express-volumes-for-mission-critical-database-workloads/
Comment: Nice to see that everyone just picked a different answer...
Comment: B for sure
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: Now EBS support io2.
Comment: Provisioned IOPS SSDs (io2) are specifically designed to deliver sustained high performance and low latency (RDS is supported in IO2). They can handle more than 20,000 IOPS.
Comment: It should be "C" right, now. https://aws.amazon.com/blogs/aws/amazon-rds-now-supports-io2-block-express-volumes-for-mission-critical-database-workloads/
Comment: C is the correct one EBS Volume Types Use cases Provisioned IOPS (PIOPS) SSD • Critical business applications with sustained IOPS performance • Or applications that need more than 16,000 IOPS • Great for databases workloads (sensitive to storage perf and consistency) • io1/io2 (4 GiB - 16 TiB): • Max PIOPS: 64,000 for Nitro EC2 instances & 32,000 for other • Can increase PIOPS independently from storage size • io2 have more durability and more IOPS per GiB (at the same price as io1) • io2 Block Express (4 GiB – 64 TiB): • Sub-millisecond latency • Max PIOPS: 256,000 with an IOPS:GiB ratio of 1,000:1
Comment: Per the newest info it should be C right now https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: ChatGpt says B
Comment: io2 is now supported by RDS as of 2024. It wasn't at one point, but people need to check the docs when they start saying it's not supported. Just because it was once true does not mean that it still is.
Comment: Hey I don't think the io2 restiction exist anymore, as from March 2024. See below.... https://aws.amazon.com/blogs/aws/amazon-rds-now-supports-io2-block-express-volumes-for-mission-critical-database-workloads/#:~:text=1%20io2%20Block%20Express%20volumes%20are%20available%20on,of%20IOPS%20to%20allocated%20storage%20is%20500%3A1.%20
Comment: Thank you, I see people saying that it is not supported everywhere. Now, a whole 'nother thing is whether AWS has updated SAA to reflect these changes. Given how terribly a lot of the REAL EXAM QUESTIONS are written, I wouldn't be surprised if they have NOT updated the exam at all
Comment: If you reached this discussion after March 5th, RDS supports io2 now:https://aws.amazon.com/blogs/aws/amazon-rds-now-supports-io2-block-express-volumes-for-mission-critical-database-workloads/
Comment: Answer D
Comment: Option C. Replace the volume with a Provisioned IOPS SSD (io2) volume. Provisioned IOPS SSD (io2) volumes allow you to specify a consistent level of IOPS to meet performance requirements. By provisioning the necessary IOPS, you can ensure that the database performance remains stable even during periods of high demand. This solution addresses the issue of performance degradation when the number of read and write IOPS exceeds 20,000.
Comment: RDS does not support io2 volume
Comment: No longer true as of 2024. It is supported now. Says right here in the first paragraphs: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
Comment: C. AWS CloudTrail The best option is to use AWS CloudTrail to find the desired information. AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of AWS account activities. CloudTrail can be used to log all changes made to resources in an AWS account, including changes made by IAM users, EC2 instances, AWS management console, and other AWS services. By using CloudTrail, the solutions architect can identify the IAM user who made the configuration changes to the security group rules.
Comment: I was initially a bit confused on what Config and CloudTrail actually do, as both can be used to track configuration changes. However, this explanation is probably the best one I have come across so far: "Config reports on what has changed, whereas CloudTrail reports on who made the change, when, and from which location" Since the question is which IAM user was responsible for making the changes, the answer is CloudTrail.
Comment: CloudTrail = which user made which api calls. This is used for audit purpose.
Comment: This question is the same with the question 388, isn't it?
Comment: This is how you know not to trust the moderators with their answers.
Comment: There is an article "How to use AWS Config and CloudTrail to find who made changes to a resource" in aws blog. Given CloudTrail provided AWS config original info, it seems for this particular one, C is better than AWS config.
Comment: AWS CloudTrail is the correct service to use here to identify which user was responsible for the security group configuration changes
Comment: AWS CloudTrail
Comment: AWS CloudTrail
Comment: C. AWS CloudTrail
Comment: CloudTrail logs will tell who did that
Comment: Option "C" AWS CloudTrail is correct.
Comment: cccccc
Comment: DDoS attacks = AWS Shield Advance Shield Advance protects Global Accelerator, NLB, ALB, etc
Comment: Global Accelerator is what is exposed to the Internet = where DDoS attacks could land = what must be protected by Shield Advanced
Comment: So, the correct option is: B. Subscribe to AWS Shield Advanced. Add the EC2 instances as resources to protect. Here's why this option is the most appropriate: A. While you can add the accelerator as a resource to protect with AWS Shield Advanced, it's generally more effective to protect the individual resources (in this case, the EC2 instances) because AWS Shield Advanced will automatically protect resources associated with Global Accelerator
Comment: Which EC2 instance? Global Accelerator works by providing anycast IP addresses for the underlying resource (our EC2 in this case) so every end user trying to reach the EC2 server HAS to go through the Global Accelerator which is why the Global Accelerator needs to be protected and not the EC2.
Comment: DDoS attacks = AWS Shield Advance resource as Global Acc
Comment: DDoS attacks = AWS Shield Advanced
Comment: Answer is A https://docs.aws.amazon.com/waf/latest/developerguide/ddos-event-mitigation-logic-gax.html
Comment: AWS Shield is a managed service that provides protection against Distributed Denial of Service (DDoS) attacks for applications running on AWS. AWS Shield Standard is automatically enabled to all AWS customers at no additional cost. AWS Shield Advanced is an optional paid service. AWS Shield Advanced provides additional protections against more sophisticated and larger attacks for your applications running on Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53.
Comment: aaaaa accelator can not be attached to shield
Comment: bbbbbbbbb
Comment: Your origin servers can be Amazon Simple Storage Service (S3), Amazon EC2, Elastic Load Balancing, or a custom server outside of AWS. You can also enable AWS Shield Advanced directly on Elastic Load Balancing or Amazon EC2 in the following AWS Regions - Northern Virginia, Ohio, Oregon, Northern California, Montreal, São Paulo, Ireland, Frankfurt, London, Paris, Stockholm, Singapore, Tokyo, Sydney, Seoul, Mumbai, Milan, and Cape Town. My answer is B
Comment: https://docs.aws.amazon.com/waf/latest/developerguide/ddos-event-mitigation-logic-gax.html Sorry I meant A
Comment: You CAN enable Shield Advanced directly on EC2. You CAN also expose EC2 instances directly to the Internet. But in this case, what is exposed to the Internet (= where DDoS attacks could land) is the Global Accelerator, not your EC2 instances.
Comment: Yes it can: AWS Shield is a managed service that provides protection against Distributed Denial of Service (DDoS) attacks for applications running on AWS. AWS Shield Standard is automatically enabled to all AWS customers at no additional cost. AWS Shield Advanced is an optional paid service. AWS Shield Advanced provides additional protections against more sophisticated and larger attacks for your applications running on Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53.
Comment: The requirement is to run a daily scheduled job to aggregate and filter sales records for analytics in the most efficient way possible. Based on the requirement, we can eliminate option A and B since they use AWS Lambda which has a limit of 15 minutes of execution time, which may not be sufficient for a job that can take up to an hour to complete. Between options C and D, option C is the better choice since it uses AWS Fargate which is a serverless compute engine for containers that eliminates the need to manage the underlying EC2 instances, making it a low operational effort solution. Additionally, Fargate also provides instant scale-up and scale-down capabilities to run the scheduled job as per the requirement. Therefore, the correct answer is: C. Create an Amazon Elastic Container Service (Amazon ECS) cluster with an AWS Fargate launch type. Create an Amazon EventBridge scheduled event that launches an ECS task on the cluster to run the job.
Comment: A&B are out due to Lambda 15 min limits C is less operationally complex than D so C is the right answer. Fargate is managed ECS cluster whereas EC2 based ECS will require more config overhead.
Comment: C. Create an Amazon Elastic Container Service (Amazon ECS) cluster with an AWS Fargate launch type. Create an Amazon EventBridge scheduled event that launches an ECS task on the cluster to run the job
Comment: The best option is C. 'The job can take up to an hour to complete' rules out lambda functions as they only execute up to 15 mins. Hence option A and B are out. 'The CPU and memory usage of the job are constant and are known in advance' rules out the need for autoscaling. Hence option D is out.
Comment: "1-hour job" -> A, B out since max duration for Lambda is 15 min Between C and D, "minimize operational effort" means Fargate -> C
Comment: The solution that meets the requirements with the least operational overhead is to create a **Regional AWS WAF web ACL with a rate-based rule** and associate the web ACL with the API Gateway stage. This solution will protect the application from HTTP flood attacks by monitoring incoming requests and blocking requests from IP addresses that exceed the predefined rate. Amazon CloudFront distribution with Lambda@Edge in front of the API Gateway Regional API endpoint is also a good solution but it requires more operational overhead than the previous solution. Using Amazon CloudWatch metrics to monitor the Count metric and alerting the security team when the predefined rate is reached is not a solution that can protect against HTTP flood attacks. Creating an Amazon CloudFront distribution in front of the API Gateway Regional API endpoint with a maximum TTL of 24 hours is not a solution that can protect against HTTP flood attacks.
Comment: The solution that meets these requirements is C. Create an Amazon Elastic Container Service (Amazon ECS) cluster with an AWS Fargate launch type. Create an Amazon EventBridge scheduled event that launches an ECS task on the cluster to run the job. This solution will minimize the amount of operational effort that is needed for the job to run. AWS Lambda which has a limit of 15 minutes of execution time,
Comment: With the existing data link the transfer takes ~ 600 days in the best case. Thus, (A) and (B) are not applicable. Solution (D) could meet the target with a transfer time of 6 days, but the lead time for the direct connect deployment can take weeks! Thus, (C) is the only valid solution.
Comment: Use the AWS Snow Family console to order several AWS Snowball Edge Storage Optimized devices. Use the devices to transfer the data to Amazon S3.
Comment: C is the best option considering the time and bandwidth limitations
Comment: We need the admin in here to tell us how they plan on this being achieved over connection with such a slow connection lol. It's C, folks.
Comment: Best option is to use multiple AWS Snowball Edge Storage Optimized devices. Option "C" is the correct one.
Comment: All others are limited by the bandwidth limit
Comment: Or provisioning time in the D case
Comment: It is C. Snowball (from Snow Family).
Comment: C. Use the AWS Snow Family console to order several AWS Snowball Edge Storage Optimized devices. Use the devices to transfer the data to Amazon S3. The best option is to use the AWS Snow Family console to order several AWS Snowball Edge Storage Optimized devices and use the devices to transfer the data to Amazon S3. Snowball Edge is a petabyte-scale data transfer device that can help transfer large amounts of data securely and quickly. Using Snowball Edge can be the most cost-effective solution for transferring large amounts of data over long distances and can help meet the requirement of transferring 600 TB of data within two weeks.
Comment: Regional AWS WAF web ACL is a managed web application firewall that can be used to protect your API Gateway API from a variety of attacks, including HTTP flood attacks. Rate-based rule is a type of rule that can be used to limit the number of requests that can be made from a single IP address within a specified period of time. API Gateway stage is a logical grouping of API resources that can be used to control access to your API.
Comment: A rate-based rule in AWS WAF allows the security team to configure thresholds that trigger rate-based rules, which enable AWS WAF to track the rate of requests for a specified time period and then block them automatically when the threshold is exceeded. This provides the ability to prevent HTTP flood attacks with minimal operational overhead.
Comment: Answer is B
Comment: B os correct
Comment: https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
Comment: bbbbbbbb
Comment: The best solution to meet these requirements with the least amount of operational overhead is to enable Amazon DynamoDB Streams on the table and use triggers to write to a single Amazon Simple Notification Service (Amazon SNS) topic to which the teams can subscribe. This solution requires minimal configuration and infrastructure setup, and Amazon DynamoDB Streams provide a low-latency way to capture changes to the DynamoDB table. The triggers automatically capture the changes and publish them to the SNS topic, which notifies the internal teams.
Comment: Answer A is not a suitable solution because it requires additional configuration to notify the internal teams, and it could add operational overhead to the application. Answer B is not the best solution because it requires changes to the current application, which may affect its performance, and it creates additional work for the teams to subscribe to multiple topics. Answer D is not a good solution because it requires a cron job to scan the table every minute, which adds additional operational overhead to the system. Therefore, the correct answer is C. Enable Amazon DynamoDB Streams on the table. Use triggers to write to a single Amazon SNS topic to which the teams can subscribe.
Comment: Enable Amazon DynamoDB Streams on the table. Use triggers to write to a single Amazon Simple Notification Service (Amazon SNS) topic to which the teams can subscribe
Comment: Question keyword: "sends an alert", a new weather event is recorded". Answer keyword C "Amazon DynamoDB Streams on the table", "Amazon Simple Notification Service" (Amazon SNS). Choose C. Easy question. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html https://aws.amazon.com/blogs/database/dynamodb-streams-use-cases-and-design-patterns/
Comment: Best answer is C
Comment: DynamoDB Streams captures a time-ordered sequence of item-level modifications in any DynamoDB table and stores this information in a log for up to 24 hours. This capture activity can also invoke triggers to write the event to a single Amazon Simple Notification Service (Amazon SNS) topic to which the teams can subscribe to.
Comment: C is correct
Comment: definitely C
Comment: DynamoDB Streams
Comment: Answer : C
Comment: cccccccc
Comment: B has app servers in a single AZ and a database on a single instance C has both DB replicas in a single AZ D does not work (EBS Multi-Attach requires EC2 instances in same AZ), and if it would work then the EBS volume would be an SPOF
Comment: Deploy the application servers by using Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones. Use an Amazon RDS DB instance in a Multi-AZ configuration
Comment: Why is C incorrect ?
Comment: C is incorrect because the read replica also resides in a single AZ
Comment: A most def.
Comment: Deploy the application servers by using Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones. Use an Amazon RDS DB instance in a Multi-AZ configuration.
Comment: The correct answer is A. Deploy the application servers by using Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones. Use an Amazon RDS DB instance in a Multi-AZ configuration. To make an existing application highly available and resilient while avoiding any single points of failure and giving the application the ability to scale to meet user demand, the best solution would be to deploy the application servers using Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones and use an Amazon RDS DB instance in a Multi-AZ configuration. By using an Amazon RDS DB instance in a Multi-AZ configuration, the database is automatically replicated across multiple Availability Zones, ensuring that the database is highly available and can withstand the failure of a single Availability Zone. This provides fault tolerance and avoids any single points of failure.
Comment: Why not D?
Comment: Answer D, deploying the primary and secondary database servers on EC2 instances across multiple Availability Zones and using Amazon Elastic Block Store (Amazon EBS) Multi-Attach to create shared storage between the instances, may provide high availability for the database but may introduce additional complexity, and management overhead, and potential performance issues.
Comment: D is incorrect because using Multi-Attach EBS adds complexity and doesn't provide automatic DB failover
Comment: Multi-Attach does not work across Availability Zones.
Comment: Highly available = Multi-AZ approach
Comment: Answers is A
Comment: Option A is the correct solution. Deploying the application servers in an Auto Scaling group across multiple Availability Zones (AZs) ensures high availability and fault tolerance. An Auto Scaling group allows the application to scale horizontally to meet user demand. Using Amazon RDS DB instance in a Multi-AZ configuration ensures that the database is automatically replicated to a standby instance in a different AZ. This provides database redundancy and avoids any single point of failure.
Comment: Highly available
Comment: No because instance and read replica "in a single Availability Zone"
Comment: Yes , agree with A
Comment: agree with that
Comment: "A Kinesis data stream stores records from 24 hours by default, up to 8760 hours (365 days)." https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html The question mentioned Kinesis data stream default settings and "every other day". After 24hrs, the data isn't in the Data stream if the default settings is not modified to store data more than 24hrs.
Comment: C. Update the number of Kinesis shards to handle the throughput of the data that is sent to Kinesis Data Streams. The best option is to update the number of Kinesis shards to handle the throughput of the data that is sent to Kinesis Data Streams. Kinesis Data Streams scales horizontally by increasing or decreasing the number of shards, which controls the throughput capacity of the stream. By increasing the number of shards, the application will be able to send more data to Kinesis Data Streams, which can help ensure that S3 receives all the data.
Comment: Answer C: C. Update the number of Kinesis shards to handle the throughput of the data that is sent to Kinesis Data Streams. - Answer C updates the number of Kinesis shards to handle the throughput of the data that is sent to Kinesis Data Streams. By increasing the number of shards, the data is distributed across multiple shards, which allows for increased throughput and ensures that all data is ingested and processed by Kinesis Data Streams. - Monitoring the Kinesis Data Streams and adjusting the number of shards as needed to handle changes in data throughput can ensure that the application can handle large amounts of streaming data.
Comment: @cegama543, my apologies. Moderator if you can disapprove of the post above? I made a mistake. It is supposed to be intended on the post that I submitted. Thanks.
Comment: lets say you had infinity shards... if the retention period is 24 hours and you get the data every 48 hours, you will lose 24 hours of data no matter the amount of shards no?
Comment: Amazon Kinesis Data Streams supports changes to the data record retention period of your data stream. A Kinesis data stream is an ordered sequence of data records meant to be written to and read from in real time. Data records are therefore stored in shards in your stream temporarily. The time period from when a record is added to when it is no longer accessible is called the retention period. A Kinesis data stream stores records from 24 hours by default, up to 8760 hours (365 days).
Comment: Answer is C Issue with A) Update the Kinesis Data Streams default settings by modifying the data retention period. is below Limitation: Modifying the data retention period affects how long data is kept in the stream, but it does not address the issue of the stream's capacity to ingest data. If the stream is unable to handle the incoming data volume, extending the retention period will not resolve the data loss issue.
Comment: Every other day, = 48 hours Default settings = 24 hours B: Development library so won't help C: More shards may retain more data but they will have same limitation of 24 hours retention D: Irrelevant A: Increase the default limit from 24 hours to 48 hours
Comment: "Default settings" = 24 hour retention
Comment: KDS has two modes: 1. Provisioned Mode: Answer C would be correct if KDS runs in this mode. We need to increase the number of shards. 2. On-Demand: Scales automatically, which means it doesn't need to adjust the number of shards based on observed throughput. And since the question does not mention which type, I would go with On-demand. Therefore, A is the correct answer.
Comment: Data records are stored in shards in a kinesis data stream temporarily. The time period from when a record is added, to when it is no longer accessible is called the retention period. This time period is 24 hours by default, but could be adjusted to 365 days. Kinesis Data Streams automatically scales the number of shards in response to changes in data volume and traffic, so this rules out option C. https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html#:~:text=the%20number%20of-,shards,-in%20response%20to
Comment: I have only voted A because it mentions the default setting in Kinesis, if it did not mention that then I would look to increase the Shards. By default it is 24 hours and can go to 365 days. I think the question should be rephrased slightly. I had trouble deciding between A & C. Also apparently the most voted answer is the correct answer as per some advice I was given.
Comment: Default retention is 24 hrs, but the data read is every other day, so the S3 will never receive the data, Change the default retention period to 48 hours.
Comment: By default, a Kinesis data stream is created with one shard. If the data throughput to the stream is higher than the capacity of the single shard, the data stream may not be able to handle all the incoming data, and some data may be lost. Therefore, to handle the high volume of data that the application sends to Kinesis Data Streams, the number of Kinesis shards should be increased to handle the required throughput. Kinesis Data Streams shards are the basic units of scalability and availability. Each shard can process up to 1,000 records per second with a maximum of 1 MB of data per second. If the application is sending more data to Kinesis Data Streams than the shards can handle, then some of the data will be dropped.
Comment: If you have doubts, Please read about Kinesis Data Streams shards. Ans: A is not the correct answer here
Comment: the default retention period is 24 hours "The default retention period of 24 hours covers scenarios where intermittent lags in processing require catch-up with the real-time data. " so we should increment this
Comment: As "Default settings" is mentioned here, I vote for A.
Comment: keyword here is - default settings and every other day and since "A Kinesis data stream stores records from 24 hours by default, up to 8760 hours (365 days)." https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html Will go with A
Comment: C is wrong because even if you update the number of Kinesis shards, you still need to change the default data retention period first. Otherwise, you would lose data after 24 hours.
Comment: A is unrelated to the issue. The correct answer is C.
Comment: Correct Ans. is B
Comment: By default, a Kinesis data stream is created with one shard. If the data throughput to the stream is higher than the capacity of the single shard, the data stream may not be able to handle all the incoming data, and some data may be lost. Therefore, to handle the high volume of data that the application sends to Kinesis Data Streams, the number of Kinesis shards should be increased to handle the required throughput
Comment: Create Lambda execution role and attach existing S3 IAM role to the lambda function
Comment: To grant the necessary permissions to an AWS Lambda function to upload files to Amazon S3, a solutions architect should create an IAM execution role with the required permissions and attach the IAM role to the Lambda function. This approach follows the principle of least privilege and ensures that the Lambda function can only access the resources it needs to perform its specific task. Therefore, the correct answer is D. Create an IAM execution role with the required permissions and attach the IAM role to the Lambda function.
Comment: Oh you're here
Comment: D. Créez un rôle d'exécution IAM avec les autorisations requises et attachez le rôle IAM à la fonction Lambda. L'architecte de solutions doit créer un rôle d'exécution IAM ayant les autorisations nécessaires pour accéder à Amazon S3 et effectuer les opérations requises (par exemple, charger des fichiers). Ensuite, le rôle doit être associé à la fonction Lambda, de sorte que la fonction puisse assumer ce rôle et avoir les autorisations nécessaires pour interagir avec Amazon S3.
Comment: Answer is D
Comment: D - correct ans
Comment: Create Lambda execution role and attach existing S3 IAM role to the lambda function
Comment: Definitely D
Comment: ddddddd
Comment: dddddddd
Comment: D. Create an Amazon Simple Queue Service (Amazon SQS) queue. Send the requests to the queue. Configure the queue as an event source for Lambd
Comment: D is the best approach
Comment: D is the correct answer
Comment: To improve the architecture of this application, the best solution would be to use Amazon Simple Queue Service (Amazon SQS) to buffer the requests and decouple the S3 bucket from the Lambda function. This will ensure that the documents are not lost and can be processed at a later time if the Lambda function is not available. This will ensure that the documents are not lost and can be processed at a later time if the Lambda function is not available. By using Amazon SQS, the architecture is decoupled and the Lambda function can process the documents in a scalable and fault-tolerant manner.
Comment: D. Créez une file d'attente Amazon Simple Queue Service (Amazon SQS). Envoyez les demandes à la file d'attente. Configurez la file d'attente en tant que source d'événement pour Lambda. Cette solution permet de gérer efficacement les pics de charge et d'éviter la perte de documents en cas d'augmentation soudaine du trafic. Lorsque de nouveaux documents sont chargés dans le compartiment Amazon S3, les demandes sont envoyées à la file d'attente Amazon SQS, qui agit comme un tampon. La fonction Lambda est déclenchée en fonction des événements dans la file d'attente, ce qui permet un traitement équilibré et évite que l'application ne soit submergée par un grand nombre de documents simultanés.
Comment: exactement. si je pouvais explique come cela en Francais aussi
Comment: D is the correct answer.
Comment: D is correct
Comment: D is correct
Comment: dddddddd
Comment: What does "ALB capacity" even means anyway? It should be "Target Group capacity" no? Answer should be DE, as D is a more comprehensive answer (and more practical in real life)
Comment: Not A - "AWS Auto Scaling" cannot adjust "ALB capacity" (https://aws.amazon.com/autoscaling/faqs/) Not B - VPC internet gateway has nothing to do with this Not C - Regions have nothing to do with scaling "The system will experience significant increases in traffic during working hours" -> addressed by D "But is not required to operate on weekends" -> addressed by E
Comment: Good explanation!
Comment: AD E - the question doesn't ask about cost. Also, shutting it down during the weekend does nothing to improve scaling during the week. It doesn't address the requirements.
Comment: The solutions architect should take actions D and E: D) Use a target tracking scaling policy to scale the Auto Scaling group based on instance CPU utilization. This will allow the Auto Scaling group to dynamically scale in and out based on demand. E) Use scheduled scaling to change the Auto Scaling group capacity to zero on weekends when traffic is expected to be low. This will minimize costs by terminating unused instances.
Comment: Basado en los requerimientos la opción que se requiere para optimizar los costos de 0 operaciones en los fines de semana
Comment: DE - This seems more close for the auto scaling - A - Its says auto scaling on ALB, but it should always be on EC2 instances and not ELB
Comment: Hi guys, very simple * A. because the question are asking abount request rate!!!! This is a requirement! * E. The weekend is not necessary to execute anything! A&D. Is not possible, way you can put an ALB capacity based in cpu and in request rate???? You need to select one or another option (and this is for all questions here guys!)
Comment: ALBRequestCountPerTarget—Average Application Load Balancer request count per target. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html#target-tracking-choose-metrics It is possible to set to zero. "is not required to operate on weekends" means the instances are not required during the weekends. https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html
Comment: A says to scale "ALB capacity", not number of EC2 instances. But "AWS Auto Scaling" cannot scale ALB capacity.
Comment: Option E is incorrect because the question specifically mentions an increase in traffic during working hours. Therefore, it is not advisable to schedule the instances for 24 hours using default settings throughout the entire week. E. Use scheduled scaling to change the Auto Scaling group minimum, maximum, and desired capacity to zero for weekends. Revert to the default values at the start of the week.
Comment: AD are the correct answs
Comment: Either one or two or all of these combinations will meet the need: Use AWS Auto Scaling to adjust the ALB capacity based on request rate. Use a target tracking scaling policy to scale the Auto Scaling group based on instance CPU utilization. Use scheduled scaling to change the Auto Scaling group minimum, maximum, and desired capacity to zero for weekends. Revert to the default values at the start of the week.
Comment: Scheduled scaling was specifically designed to handle these kind of requirements. I therefore take out target scaling. https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html#:~:text=RSS-,Scheduled%20scaling,-helps%20you%20to
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html#target-tracking-choose-metrics Based on docs, ASG can't track ALB's request rate, so the answer is D&E meanwhile ASG can track CPU rates.
Comment: The link shows: ALBRequestCountPerTarget—Average Application Load Balancer request count per target.
Comment: Scaling should be at the ASG not ALB. So, not sure about "Use AWS Auto Scaling to adjust the ALB capacity based on request rate"
Comment: A. Use AWS Auto Scaling to adjust the ALB capacity based on request rate: This will allow the system to scale up or down based on incoming traffic demand. The solutions architect should use AWS Auto Scaling to monitor the request rate and adjust the ALB capacity as needed. D. Use a target tracking scaling policy to scale the Auto Scaling group based on instance CPU utilization: This will allow the system to scale up or down based on the CPU utilization of the EC2 instances in the Auto Scaling group. The solutions architect should use a target tracking scaling policy to maintain a specific CPU utilization target and adjust the number of EC2 instances in the Auto Scaling group accordingly.
Comment: Auto scaling for ALB capacity?
Comment: A. Use a target tracking scaling policy to scale the Auto Scaling group based on instance CPU utilization. This approach allows the Auto Scaling group to automatically adjust the number of instances based on the specified metric, ensuring that the system can scale to meet demand during working hours. D. Use scheduled scaling to change the Auto Scaling group minimum, maximum, and desired capacity to zero for weekends. Revert to the default values at the start of the week. This approach allows the Auto Scaling group to reduce the number of instances to zero during weekends when traffic is expected to be low. It will help the organization to save costs by not paying for instances that are not needed during weekends. Therefore, options A and D are the correct answers. Options B and C are not relevant to the scenario, and option E is not a scalable solution as it would require manual intervention to adjust the group capacity every week.
Comment: This is why I don't believe A is correct use auto scaling to adjust the ALB .... D&E
Comment: Autoscaling can't scale the ALB
Comment: AD D there is no requirement for cost minimization in the scenario therefore, A & D are the answers
Comment: Remember guys that SG is not used for Deny action, just Allow
Comment: The following are the default rules for a security group that you create: Allows no inbound traffic Allows all outbound traffic
Comment: 'must be accessible only to the web servers' is the key here. Option B almost threw me off, but with this then all that exists in the public subnet would be able to access the DB security group. Therefore C,D well applies the principle of least privilege.
Comment: Remember guys that SG is not used for Deny action, just Allow
Comment: To meet the requirements of allowing access to the web servers in the public subnet on port 443 and the Amazon RDS for MySQL DB instance in the database subnet on port 3306, the best solution would be to create a security group for the web servers and another security group for the DB instance, and then define the appropriate inbound and outbound rules for each security group. 1. Create a security group for the web servers in the public subnet. Add a rule to allow traffic from 0.0.0.0/0 on port 443. 2. Create a security group for the DB instance. Add a rule to allow traffic from the web servers' security group on port 3306. This will allow the web servers in the public subnet to receive traffic from the internet on port 443, and the Amazon RDS for MySQL DB instance in the database subnet to receive traffic only from the web servers on port 3306.
Comment: CD - Correct ans.
Comment: I choose CE
Comment: CE support @sitha
Comment: Answer: CE . The solution is to deny accessing DB from Internet and allow only access from webserver.
Comment: C & D are the right choices. correct
Comment: why not CE?
Comment: Characteristics of security group rules You can specify allow rules, but not deny rules. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
Comment: By default Security Group deny all trafic and we need to configure to enable.
Comment: cdcdcdcdcdc
Comment: To meet the requirements of a shared storage solution for a gaming application that can be accessed using Lustre clients and is fully managed, the best solution would be to use Amazon FSx for Lustre. Amazon FSx for Lustre is a fully managed file system that is optimized for compute-intensive workloads, such as high-performance computing, machine learning, and gaming. It provides a POSIX-compliant file system that can be accessed using Lustre clients and offers high performance, scalability, and data durability. This solution provides a highly available, scalable, and fully managed shared storage solution that can be accessed using Lustre clients. Amazon FSx for Lustre is optimized for compute-intensive workloads and provides high performance and durability.
Comment: Answer A, creating an AWS DataSync task that shares the data as a mountable file system and mounting the file system to the application server, may not provide the required performance and scalability for a gaming application. Answer B, creating an AWS Storage Gateway file gateway and connecting the application server to the file share, may not provide the required performance and scalability for a gaming application. Answer C, creating an Amazon Elastic File System (Amazon EFS) file system and configuring it to support Lustre, may not provide the required performance and scalability for a gaming application and may require additional configuration and management overhead.
Comment: Lustre clients = Amazon FSx for Lustre file system
Comment: Lustre clients = Amazon FSx for Lustre file system
Comment: D - correct ans
Comment: FSx for Lustre DDDDDD
Comment: Amazon FSx for Lustre is the right answer • Lustre is a type of parallel distributed file system, for large-scale computing, Machine Learning, High Performance Computing (HPC) • Video Processing, Financial Modeling, Electronic Design Automatio
Comment: Option D is the best solution because Amazon FSx for Lustre is a fully managed, high-performance file system that is designed to support compute-intensive workloads, such as those required by gaming applications. FSx for Lustre provides sub-millisecond access to petabyte-scale file systems, and supports Lustre clients natively. This means that the gaming application can access the shared data directly from the FSx for Lustre file system without the need for additional configuration or setup. Additionally, FSx for Lustre is a fully managed service, meaning that AWS takes care of all maintenance, updates, and patches for the file system, which reduces the operational overhead required by the company.
Comment: dddddddddddd
Comment: Key words: geographically dispersed, UDP. Geographically dispersed (related to UDP) - Global Accelerator - multiple entrances worldwide to the AWS network to provide better transfer rates. UDP - NLB (Network Load Balancer).
Comment: if its UDP it has to be Global Accelarator + NLB package, plus it has the provision for rapid failover as well, piece of cake.
Comment: UDP: NLB + AWS Global Accelerator
Comment: UDP/TCP=NLB rapid failover= AWS global accelerator
Comment: devices that use UDP = NLB
Comment: minimizes latency = AWS Global Accelerator
Comment: This option meets the requirements: Global Accelerator provides UDP support and minimizes latency using the AWS global network. Using NLBs allows the UDP traffic to be load balanced across Availability Zones. ECS Fargate provides rapid scaling and failover across Regions. NLB endpoints allow rapid failover if one Region goes down.
Comment: UDP = AWS Global Accelerator and Network Load Balancer
Comment: Global accelerator for multi region automatic failover. NLB for UDP.
Comment: why not A?
Comment: NLBs do not support lambda target type. Tricky!!! https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html
Comment: To meet the requirements of minimizing latency for data transmission from the devices and providing rapid failover to another AWS Region, the best solution would be to use AWS Global Accelerator in combination with a Network Load Balancer (NLB) and Amazon Elastic Container Service (Amazon ECS). AWS Global Accelerator is a service that improves the availability and performance of applications by using static IP addresses (Anycast) to route traffic to optimal AWS endpoints. With Global Accelerator, you can direct traffic to multiple Regions and endpoints, and provide automatic failover to another AWS Region.
Comment: Answer should be B.. there is typo mistake in B. Correct Answer is : Use AWS Global Accelerator. Create a Network Load Balancer (NLB) in each of the two Regions as an endpoint. Create an Amazon Elastic Container Service (Amazon ECS) cluster with the Fargate launch type. Create an ECS service on the cluster. Set the ECS service as the target for the NLB. Process the data in Amazon ECS.
Comment: bbbbbbbb
Comment: A) RDS is a database service B) Storage Gateway is a hybrid cloud storage service that connects on-premises applications to AWS storage services. D) provides shared file storage for Linux-based workloads, but it does not natively support Windows-based workloads.
Comment: The most resilient and durable replacement for the on-premises file share in this scenario would be Amazon FSx for Windows File Server. Amazon FSx is a fully managed Windows file system service that is built on Windows Server and provides native support for the SMB protocol. It is designed to be highly available and durable, with built-in backup and restore capabilities. It is also fully integrated with AWS security services, providing encryption at rest and in transit, and it can be configured to meet compliance standards.
Comment: Migrating the file share to Amazon RDS or AWS Storage Gateway is not appropriate as these services are designed for database workloads and block storage respectively, and do not provide native support for the SMB protocol. Migrating the file share to Amazon EFS (Linux ONLY) could be an option, but Amazon FSx for Windows File Server would be more appropriate in this case because it is specifically designed for Windows file shares and provides better performance for Windows applications.
Comment: Windows Server to FSx For Windows
Comment: Windows client = Amazon FSx for Windows File Serve
Comment: Windows client = Amazon FSx for Windows File Server
Comment: Obviously C is the correct answer - FSx for Windows - Windows
Comment: FSx for Windows - Windows. EFS - Linux.
Comment: good summary
Comment: Amazon EFS is a scalable and fully-managed file storage service that is designed to provide high availability and durability. It can be accessed by multiple EC2 instances across multiple Availability Zones simultaneously. Additionally, it offers automatic and instantaneous data replication across different availability zones within a region, which makes it resilient to failures.
Comment: EFS is a wrong choice because it can only work with Linux instances. That application has a Windows web server , so its OS is Windows and EFS cannot connect to it
Comment: Amazon FSx
Comment: Amazon FSx makes it easy and cost effective to launch, run, and scale feature-rich, high-performance file systems in the cloud. Answer : C
Comment: FSx for Windows is a fully managed Windows file system share drive . Hence C is the correct answer.
Comment: FSx for Windows is ideal in this case. So answer is C.
Comment: ccccccccc
Comment: The solution that will meet the requirement of ensuring that all data that is written to the EBS volumes is encrypted at rest is B. Create the EBS volumes as encrypted volumes and attach the encrypted EBS volumes to the EC2 instances. When you create an EBS volume, you can specify whether to encrypt the volume. If you choose to encrypt the volume, all data written to the volume is automatically encrypted at rest using AWS-managed keys. You can also use customer-managed keys (CMKs) stored in AWS KMS to encrypt and protect your EBS volumes. You can create encrypted EBS volumes and attach them to EC2 instances to ensure that all data written to the volumes is encrypted at rest. Answer A is incorrect because attaching an IAM role to the EC2 instances does not automatically encrypt the EBS volumes. Answer C is incorrect because adding an EC2 instance tag does not ensure that the EBS volumes are encrypted.
Comment: B is the answer
Comment: B. Create the EBS volumes as encrypted volumes. Attach the EBS volumes to the EC2 instances.
Comment: Windows client = Amazon FSx for Windows File Server
Comment: ignore this, mind stuck on last question hhhhhh. Just create the EBS volumes as encrypted volumes then attach the EBS volumes to the EC2 instances.
Comment: The other options either do not meet the requirement of encrypting data at rest (A and C) or do so in a more complex or less efficient manner (D).
Comment: Why not D, EBS encryption require the use of KMS key
Comment: Answer D is incorrect because creating a KMS key policy that enforces EBS encryption does not automatically encrypt EBS volumes. You need to create encrypted EBS volumes and attach them to EC2 instances to ensure that all data written to the volumes are encrypted at rest.
Comment: Create encrypted EBS volumes and attach encrypted EBS volumes to EC2 instances..
Comment: Use Amazon EBS encryption as an encryption solution for your EBS resources associated with your EC2 instances.Select KMS Keys either default or custom
Comment: Answer B. You can enable encryption for EBS volumes while creating them.
Comment: bbbbbbbb
Comment: C: Aurora Serverless is a MySQL-compatible relational database engine that automatically scales compute and memory resources based on application usage. no upfront costs or commitments required. A: DynamoDB is a NoSQL B: Fixed cost on RDS class D: More operation requires
Comment: The is a huge demand for auto-scaling which Amazon RDS cannot do. This contributes to the cost savings as Aurora serverless would scale done in low peak times, this contributes to low costs.
Comment: RDS is cheaper than Aurora.
Comment: RDS is cheaper than Aurora if you have a fixed instance size, but NOT if you have "unpredictable" usage patterns, then Aurora Serverless (!) is cheaper.
Comment: Answer C, MySQL-compatible Amazon Aurora Serverless, would be the best solution to meet the company's requirements.
Comment: Since we have sporadic & unpredictable usage for DB, Aurora Serverless would be fit more cost-efficient for this case scenario than RDS MySQL. https://www.techtarget.com/searchcloudcomputing/answer/When-should-I-use-Amazon-RDS-vs-Aurora-Serverless
Comment: C for sure.
Comment: Answer C, MySQL-compatible Amazon Aurora Serverless, would be the best solution to meet the company's requirements. Aurora Serverless can be a cost-effective option for databases with sporadic or unpredictable usage patterns since it automatically scales up or down based on the current workload. Additionally, Aurora Serverless is compatible with MySQL, so it does not require any modifications to the application's database code.
Comment: Amazon RDS for MySQL is a cost-effective database platform that will not require database modifications. It makes it easier to set up, operate, and scale MySQL deployments in the cloud. With Amazon RDS, you can deploy scalable MySQL servers in minutes with cost-efficient and resizable hardware capacity². Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. DynamoDB is a good choice for applications that require low-latency data access¹. MySQL-compatible Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora (MySQL-compatible edition), where the database will automatically start up, shut down, and scale capacity up or down based on your application's needs³. So, Amazon RDS for MySQL is the best option for your requirements.
Comment: sorry i will change to C , because Amazon RDS for MySQL is a fully-managed relational database service that makes it easy to set up, operate, and scale MySQL deployments in the cloud. Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora (MySQL-compatible edition), where the database will automatically start up, shut down, and scale capacity up or down based on your application's needs. It is a simple, cost-effective option for infrequent, intermittent, or unpredictable workloads.
Comment: Amazon Aurora Serverless : a simple, cost-effective option for infrequent, intermittent, or unpredictable workloads
Comment: cccccccccccccccccccc
Comment: Answer is D ladies and gentlemen. While guard duty helps to monitor s3 for potential threats its a reactive action. We should always be proactive and not reactive in our solutions so D, block public access to avoid any possibility of the info becoming publicly accessible
Comment: Answer D is the correct solution that meets the requirements. The S3 Block Public Access feature allows you to restrict public access to S3 buckets and objects within the account. You can enable this feature at the account level to prevent any S3 bucket from being made public, regardless of the bucket policy settings. AWS Organizations can be used to apply a Service Control Policy (SCP) to the account to prevent IAM users from changing this setting, ensuring that all S3 objects remain private. This is a straightforward and effective solution that requires minimal operational overhead.
Comment: its 1 aws account, how could D be the answer?
Comment: Use the S3 Block Public Access feature on the account level. Use AWS Organizations to create a service control policy (SCP) that prevents IAM users from changing the setting. Apply the SCP to the account
Comment: Use the S3 Block Public Access feature on the account level. Use AWS Organizations to create a service control policy (SCP) that prevents IAM users from changing the setting. Apply the SCP to the account
Comment: A is correct!
Comment: No, first it would not remove any existing public access (only detect changes), second it would just detect and then remediate, but in the meantime someone could access the objects. It's clearly D.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
Comment: This is the most effective solution to meet the requirements.
Comment: Option D provided real solution by using bucket policy to restrict public access. Other options were focus on detection which wasn't what was been asked
Comment: Amazon SES is a cost-effective and scalable email service that enables businesses to send and receive email using their own email addresses and domains. Configuring the web instance to send email through Amazon SES is a simple and effective solution that can reduce the time spent resolving complex email delivery issues and minimize operational overhead.
Comment: The best option for addressing the company's needs of minimizing operational overhead and reducing time spent resolving email delivery issues is to use Amazon Simple Email Service (Amazon SES). Answer A of creating a separate application tier for email processing may add additional complexity to the architecture and require more operational overhead. Answer C of using Amazon Simple Notification Service (Amazon SNS) is not an appropriate solution for sending marketing and order confirmation emails since Amazon SNS is a messaging service that is designed to send messages to subscribed endpoints or clients. Answer D of creating a separate application tier using EC2 instances dedicated to email processing placed in an Auto Scaling group is a more complex solution than necessary and may result in additional operational overhead.
Comment: B meet these requirements
Comment: Amazon Simple Email Service (Amazon SES) lets you reach customers confidently without an on-premises Simple Mail Transfer Protocol (SMTP) email server using the Amazon SES API or SMTP interface.
Comment: B. Configure the web instance to send email through Amazon Simple Email Service (Amazon SES)
Comment: Answer is B
Comment: Answer B.. SES is meant for sending high volume e-mail efficiently and securely. SNS is meant as a channel publisher/subscriber service
Comment: bbbbbbbb
Comment: Both Amazon S3 File Gateway and AWS DataSync are suitable for this scenario. But there is a requirement for 'LEAST administrative overhead'. Option C involves the creation of an entirely new application to consume the DataSync API, this rules out this option.
Comment: Key words: 1. near-real-time (A is out) 2. LEAST administrative (C n D is out)
Comment: This option has the least administrative overhead because: Using DataSync avoids having to rewrite the business system to use a new file gateway or SFTP endpoint. Calling the DataSync API from an application allows automating the data transfer instead of running scheduled tasks or scripts. DataSync directly transfers files from the network share to S3 without needing an intermediate server
Comment: "Create an application" hell no, the application must run somewhere etc., this is massive "administrative overhead".
Comment: B. Data Sync is better for one time migrations.
Comment: The correct solution here is: B. Create an Amazon S3 File Gateway. Update the business system to use a new network share from the S3 File Gateway. This option requires the least administrative overhead because: - It presents a simple network file share interface that the business system can write to, just like a standard network share. This requires minimal changes to the business system. - The S3 File Gateway automatically uploads all files written to the share to an S3 bucket in the background. This handles the transfer and upload to S3 without requiring any scheduled tasks, scripts or automation. - All ongoing management like monitoring, scaling, patching etc. is handled by AWS for the S3 File Gateway.
Comment: The other options would require more ongoing administrative effort: A) AWS DataSync would require creating and managing scheduled tasks and monitoring them. C) Using the DataSync API would require developing an application and then managing and monitoring it. D) The SFTP option would require creating scripts, managing SFTP access and keys, and monitoring the file transfer process. So overall, the S3 File Gateway requires the least amount of ongoing management and administration as it presents a simple file share interface but handles the upload to S3 in a fully managed fashion. The business system can continue writing to a network share as is, while the files are transparently uploaded to S3. The S3 File Gateway is the most hands-off, low-maintenance solution in this scenario.
Comment: A - creating a scheduled task is not near-real time. B - The S3 File Gateway caches frequently accessed data locally and automatically uploads it to Amazon S3, providing near-real-time access to the data. C - creating an application that uses the DataSync API in the automation workflow may provide near-real-time data access, but it requires additional development effort. D - it requires additional development effort.
Comment: It's B. DataSync has a scheduler and it runs on hour intervals, it cannot be used real-time
Comment: The correct answer is C. Use AWS DataSync to transfer the files to Amazon S3. Create an application that uses the DataSync API in the automation workflow. To store the CSV reports generated by the business system in the AWS Cloud in near-real time for analysis, the best solution with the least administrative overhead would be to use AWS DataSync to transfer the files to Amazon S3 and create an application that uses the DataSync API in the automation workflow. AWS DataSync is a fully managed service that makes it easy to automate and accelerate data transfer between on-premises storage systems and AWS Cloud storage, such as Amazon S3. With DataSync, you can quickly and securely transfer large amounts of data to the AWS Cloud, and you can automate the transfer process using the DataSync API.
Comment: Answer A, using AWS DataSync to transfer the files to Amazon S3 and creating a scheduled task that runs at the end of each day, is not the best solution because it does not meet the requirement of storing the CSV reports in near-real time for analysis. Answer B, creating an Amazon S3 File Gateway and updating the business system to use a new network share from the S3 File Gateway, is not the best solution because it requires additional configuration and management overhead. Answer D, deploying an AWS Transfer for the SFTP endpoint and creating a script to check for new files on the network share and upload the new files using SFTP, is not the best solution because it requires additional scripting and management overhead
Comment: I think B is the better answer, "LEAST administrative overhead" https://aws.amazon.com/storagegateway/file/?nc1=h_ls
Comment: B - S3 File Gateway. C - this is wrong answer because data migration is scheduled (this is not continuous task), so condition "near-real time" is not fulfilled
Comment: C is the best ans
Comment: Why not A? There is no scheduled job?
Comment: Unknown access patterns for the data = S3 Intelligent-Tiering
Comment: Create an S3 Lifecycle configuration with a rule to transition the objects in the S3 bucket to S3 Intelligent-Tiering.
Comment: Key words: 'The company does not know access patterns for all the data', so A.
Comment: The correct answer is A. Creating an S3 Lifecycle configuration with a rule to transition the objects in the S3 bucket to S3 Intelligent-Tiering would be the most efficient solution to optimize the cost of S3 usage. S3 Intelligent-Tiering is a storage class that automatically moves objects between two access tiers (frequent and infrequent) based on changing access patterns. It is a cost-effective solution that does not require any manual intervention to move data to different storage classes, unlike the other options.
Comment: Answer B, Using the S3 storage class analysis tool to determine the correct tier for each object and manually moving objects to the identified storage tier would be time-consuming and require more operational overhead. Answer C, Transitioning objects to S3 Glacier Instant Retrieval would be appropriate for data that is accessed less frequently and does not require immediate access. Answer D, S3 One Zone-IA would be appropriate for data that can be recreated if lost and does not require the durability of S3 Standard or S3 Standard-IA.
Comment: For me is A. Create an S3 Lifecycle configuration with a rule to transition the objects in the S3 bucket to S3 Intelligent-Tiering. Why? "S3 Intelligent-Tiering is the ideal storage class for data with unknown, changing, or unpredictable access patterns" https://aws.amazon.com/s3/storage-classes/intelligent-tiering/
Comment: Once the data traffic is unpredictable, Intelligent-Tiering is the best option
Comment: Create an S3 Lifecycle configuration with a rule to transition the objects in the S3 bucket to S3 Intelligent-Tiering.
Comment: A: as exact pattern is not clear
Comment: To resolve the issue of slow page loads for a rapidly growing e-commerce website hosted on AWS, a solutions architect can take the following two actions: 1. Set up an Amazon CloudFront distribution 2. Create a read replica for the RDS DB instance Configuring an Amazon Redshift cluster is not relevant to this issue since Redshift is a data warehousing service and is typically used for the analytical processing of large amounts of data. Hosting the dynamic web content in Amazon S3 may not necessarily improve performance since S3 is an object storage service, not a web application server. While S3 can be used to host static web content, it may not be suitable for hosting dynamic web content since S3 doesn't support server-side scripting or processing. Configuring a Multi-AZ deployment for the RDS DB instance will improve high availability but may not necessarily improve performance.
Comment: A - Redshift is for OLAP, not OLTP B - Caching, reduces page load time and server load C - S3 can't host dynamic (!) content D - Read Replica is meant for increasing DB performance E - Multi-AZ is meant for HA (not asked here)
Comment: The two options that will best help resolve the slow page loads are: B) Set up an Amazon CloudFront distribution and E) Configure a Multi-AZ deployment for the RDS DB instance Explanation: CloudFront can cache static content globally and improve latency for static content delivery. Multi-AZ RDS improves performance and availability of the database driving dynamic content.
Comment: Wrong. Multi-AZ is meant to "enhance availability by deploying a standby instance in a second AZ, and achieve fault tolerance in the event of an AZ or database instance failure." It does not improve performance.
Comment: BD is correct.
Comment: Resolve latency = Amazon CloudFront distribution and read replica for the RDS DB
Comment: B and D
Comment: The website's users are experiencing slow page loads. To resolve this issue, a solutions architect should take the following two actions: Create a read replica for the RDS DB instance. This will help to offload read traffic from the primary database instance and improve performance.
Comment: Question asked about performance improvements, not HA. Cloudfront & Read Replica
Comment: slow page loads. >>> D
Comment: Read Replica will speed up Reads on RDS DB. E is wrong. It brings HA but doesn't contribute to speed which is impacted in this case. Multi-AZ is Active-Standby solution.
Comment: I agree with B & E. B. Set up an Amazon CloudFront distribution. (Amazon CloudFront is a content delivery network (CDN) service) E. Configure a Multi-AZ deployment for the RDS DB instance. (Good idea for loadbalance the DB workflow)
Comment: Multi-AZ for HA, Read Replica for Scalability https://aws.amazon.com/rds/features/read-replicas/?nc1=h_ls
Comment: B and E ( as there is nothing mention about read transactions)
Comment: Why E? There is nothing mentioned about High Availability also. E is wrong because Multi AZ won't help with scaling
Comment: Cloudfront and Read Replica. We don't need HA here.
Comment: Cloud Front and Read Replica
Comment: Amazon CloudFront can handle both static and Dynamic contents hence there is not need for option C l.e hosting the static data on Amazon S3. RDS read replica will reduce the amount of reads on the RDS hence leading a better performance. Multi-AZ is for disaster Recovery , which means D is also out.
Comment: CloudFont with S3
Comment: S3 can't host "dynamic content"
Comment: B and E
Comment: well, if you made it this far, it means you are persistent :) Good luck with your exam!
Comment: thank you!
Comment: Thanks good luck for all
Comment: By adding the development account as a principal in the trust policy of the IAM role in the production account, you are allowing users from the development account to assume the role in the production account. This allows the team members to access the S3 bucket in the production account without granting them unnecessary privileges.
Comment: Add the development account as a principal in the trust policy of the role in the production account
Comment: The best solution is B) Add the development account as a principal in the trust policy of the role in the production account. This allows cross-account access to the S3 bucket in the production account by assuming the IAM role. The development account users can assume the role to gain temporary access to the production bucket.
Comment: https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/ An AWS account accesses another AWS account – This use case is commonly referred to as a cross-account role pattern. It allows human or machine IAM principals from one AWS account to assume this role and act on resources within a second AWS account. A role is assumed to enable this behavior when the resource in the target account doesn't have a resource-based policy that could be used to grant cross-account access.
Comment: About Trust policy – The trust policy defines which principals can assume the role, and under which conditions. A trust policy is a specific type of resource-based policy for IAM roles. Answer A: overhead permission Admin to development. Answer C: Block public access is a security best practice and seems not relevant to this scenario. Answer D: difficult to manage and scale
Comment: Answer A, attaching the Administrator Access policy to development account users, provides too many permissions and violates the principle of least privilege. This would give users more access than they need, which could lead to security issues if their credentials are compromised. Answer C, turning off the S3 Block Public Access feature, is not a recommended solution as it is a security best practice to enable S3 Block Public Access to prevent accidental public access to S3 buckets. Answer D, creating a user in the production account with unique credentials for each team member, is also not a recommended solution as it can be difficult to manage and scale for large teams. It is also less secure, as individual user credentials can be more easily compromised.
Comment: The solution that will meet these requirements while complying with the principle of least privilege is to add the development account as a principal in the trust policy of the role in the production account. This will allow team members to access Amazon S3 buckets in two different AWS accounts while complying with the principle of least privilege. Option A is not recommended because it grants too much access to development account users. Option C is not relevant to this scenario. Option D is not recommended because it does not comply with the principle of least privilege.
Comment: B is the correct answer
Comment: The correct answer is (C) and (E). Option (C): Creating an SCP and attaching it to the root organizational unit (OU) will deny the ec2:CreateVolume action when the ec2:Encrypted condition equals false. This means that any IAM user or root user in any account in the organization will not be able to create an EBS volume without encrypting it. Option (E): Specifying the Default EBS volume encryption setting in the Organizations management account will ensure that all new EBS volumes created in any account in the organization are encrypted by default.
Comment: CE Prevent future issues by creating a SCP and set a default encryption.
Comment: The problem here is we don't know in which account the workload is on. The account in ap-xx-is that the management account or it's a member account?? That will decide to select either A or E. C is certainly correct
Comment: (A) is incorrect bc absent of SCP or the Organizations management account, the scope of the EC2 console is too narrow to be applied to 'any IAM user or root user'.
Comment: https://repost.aws/knowledge-center/ebs-automatic-encryption Newly created Amazon EBS volumes aren't encrypted by default. However, you can turn on default encryption for new EBS volumes and snapshot copies that are created within a specified Region. To turn on encryption by default, use the Amazon Elastic Compute Cloud (Amazon EC2) console.
Comment: A: will enforce automatic encryption in a account. This will have no effect on employees. Do this in every account. B: permission boundary is not appropriate here. C: an SCP will force employees to create encrypted volumes in every account. D: This would work but is too much maintenance. E: Setting EBS volume encryption in the Organizations management account will only have impact on volumes in that account, not on other accounts.
Comment: The solution should "have minimal effect on employees who create EBS volumes". Thus new volumes should automatically be encrypted. Options B, C and D do NOT automatically encrypt volumes, they simply cause requests to create non-encrypted volumes to fail.
Comment: IMO the correct solution is AC: In the Amazon EC2 console, select the EBS encryption account attribute and define a default encryption key. -> This has to be done in every AWS account separately. Create an SCP. Attach the SCP to the root organizational unit (OU). Define the SCP to deny the ec2:CreateVolume action whenthe ec2:Encrypted condition equals false. -> This will just act as a safeguard in case an admin would disable default encryption in the member account, so it should not have any effect on employees who create EBS volumes. I think an updated question would offer options A and an updated C: Create an SCP. Attach the SCP to the root organizational unit (OU). Define the SCP to deny the ec2:DisableEbsEncryptionByDefault action. -> This will prevent disabling default encryption once is has been enabled.
Comment: Wondering if just C would be sufficient?
Comment: Seems many people selected E as part of the correct answer. But I didn't find so called Organization level EBS default setting in my Organization management account. I tried setting default EBS encryption setting in my Organization management account, and it didn't apply to the member account. If E cannot guarantee default encryption in all other account, E has no advantage over A. Anyone can explain why E is better than A?
Comment: Option A: By default, EBS encryption is not enabled for EC2 instances. However, you can set an EBS encryption by default in your AWS account in the Amazon EC2 console. This ensures that every new EBS volume that is created is encrypted. Option E: With AWS Organizations, you can centrally set the default EBS encryption for your organization's accounts. This helps in enforcing a consistent encryption policy across your organization. Option B, C and D are not correct because while you can use IAM policies or SCPs to restrict the creation of unencrypted EBS volumes, this could potentially impact employees' ability to create necessary resources if not properly configured. They might require additional permissions management, which is not mentioned in the requirements. By setting the EBS encryption by default at the account or organization level (Options A and E), you can ensure all new volumes are encrypted without affecting the ability of employees to create resources.
Comment: SCPs are a great way to enforce policies across an entire AWS Organization, preventing users from creating resources that do not comply with the set policies. In AWS Management Console, one can go to EC2 dashboard -> Settings -> Data encryption -> Check "Always encrypt new EBS volumes" and choose a default KMS key. This ensures that every new EBS volume created will be encrypted by default, regardless of how it is created.
Comment: 1000% CE crt
Comment: Encryption by default allows you to ensure that all new EBS volumes created in your account are always encrypted, even if you don't specify encrypted=true request parameter. https://aws.amazon.com/blogs/compute/must-know-best-practices-for-amazon-ebs-encryption/
Comment: CとEが正しいと考える。
Comment: CE for me as well
Comment: SCP that denies the ec2:CreateVolume action when the ec2:Encrypted condition equals false. This will prevent users and service accounts in member accounts from creating unencrypted EBS volumes in the ap-southeast-2 Region.
Comment: agreed
Comment: Wouldn't this have "effect on employees who create EBS volumes", which we are asked to minimize?
Comment: A - multi-az instance : failover takes between 60-120 sec D - multi-az cluster: failover around 35 sec
Comment: They want to keep cost low as possible, A is the right answer
Comment: No, the question clearly says "failover support in most scenarios in less than 40 seconds." D is the only possible answer.
Comment: The correct answer is: D. Use an Amazon RDS Multi-AZ DB cluster deployment. Point the read workload to the reader endpoint. Explanation: The company wants high availability, automatic failover support in less than 40 seconds, read offloading from the primary instance, and cost-effectiveness. Answer D is the best choice for several reasons: 1. Amazon RDS Multi-AZ deployments provide high availability and automatic failover support. 2. In a Multi-AZ DB cluster, Amazon RDS automatically provisions and maintains a standby in a different Availability Zone. If a failure occurs, Amazon RDS performs an automatic failover to the standby, minimizing downtime. 3. The "Reader endpoint" for an Amazon RDS DB cluster provides load-balancing support for read-only connections to the DB cluster. Directing read traffic to the reader endpoint helps in offloading read operations from the primary instance.
Comment: Sorry I'm a bit confused... I thought only Aurora DB Cluster has reader endpoint. Do you by any chance has the link to the doc for RDS Reader Endpoint?
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts-connection-management.html#multi-az-db-clusters-concepts-connection-management-endpoints-reader
Comment: to offload read we use read replicas also there is no such thing as reader endpoint in rds, it is only on aurora
Comment: https://aws.amazon.com/rds/features/multi-az/ Amazon RDS Multi-AZ with two readable standbys
Comment: I think the cluster is over-kill - but the company 'wants to use an Amazon RDS ... DB cluster'.
Comment: A would be cheapest but "failover times are typically 60–120 seconds" which does not meet our requirements. We need Multi-AZ DB cluster (not instance). This has a reader endpoint by default, thus no need for additional read replicas (to "keep costs as low as possible"). https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html
Comment: in question, it has mentioned that "keep costs as low as possible" In a Multi-AZ configuration, the DB instances and EBS storage volumes are deployed across two Availability Zones. It provides high availability and failover support for DB instances. This setup is primarily for disaster recovery. It involves a primary DB instance and a standby replica, which is a copy of the primary DB instance. The standby replica is not accessible directly; instead, it serves as a failover target in case the primary instance fails.
Comment: It is D. A is not correct. Multi-AZ DB instance deployment, which creates a primary instance and a standby instance to provide failover support. However, the standby instance does not serve traffic.
Comment: https://aws.amazon.com/blogs/database/choose-the-right-amazon-rds-deployment-option-single-az-instance-multi-az-instance-or-multi-az-database-cluster/#:~:text=Unlike%20Multi%2DAZ%20instance%20deployment,different%20AZs%20serving%20read%20traffic. According to this the answer is D "Unlike Multi-AZ instance deployment, where the secondary instance can't be accessed for read or writes, Multi-AZ DB cluster deployment consists of primary instance running in one AZ serving read-write traffic and two other standby running in two different AZs serving read traffic." You don't have to create read replicas with cluster deployment so B is out.
Comment: D Fail-over on Multi-AZ DB instance is 60-120s On Cluster, the time under 35s
Comment: D. Use an Amazon RDS Multi-AZ DB cluster deployment. Point the read workload to the reader endpoint
Comment: Use an Amazon RDS Multi-AZ DB cluster deployment Point the read workload to the reader endpoint.
Comment: The solutions architect should use an Amazon RDS Multi-AZ DB instance deployment. The company can create one read replica and point the read workload to the read replica. Amazon RDS provides high availability and failover support for DB instances using Multi-AZ deployments.
Comment: and d.. Multi-AZ DB clusters typically have lower write latency when compared to Multi-AZ DB instance deployments. They also allow read-only workloads to run on reader DB instances.
Comment: This is as case where both option A and D can work, but option D gives 2 DB instances for read compared to only 1 given by option A. Costwise they are the same as both options use 3 DB instances.
Comment: lowest cost option, and effective with read replica
Comment: It's D. Read well: "A company wants to use an Amazon RDS for PostgreSQL DB CLUSTER".
Comment: First Serverless - EFS Second it says it is attached to the Linux instances at the same time, only EFS can do that.
Comment: Not A - Transfer Family canj't use EBS B - Possible and meets requirement Not C - S3 doesn't guarantee "high IOPS performance"; also there is no "public endpoint that allows only trusted IP addresses" (you can assign a Security Group to a public endpoint but that is not mentioned here) Not D - Endpoint would be in private subnet, not accessible from Internet at all
Comment: Option B best meets the company's requirements by leveraging AWS Transfer Family with an EFS volume, ensuring high availability, security, and performance.
Comment: A is incorrect as EBS is not an option C is incorrect as when I select public accessible, I don't see an option I can set up trusted IP address D isi incorrect as it is internal. B, followed the steps and I can set up a sftp in this way
Comment: B EFS has lower latency and higher throughput than S3 when accessed from within the same availability zone.
Comment: C: Because it is server-less. deffinitely not A or B because it utilizes server.
Comment: Amazon Elastic File System - Serverless, fully elastic file storage: https://aws.amazon.com/efs/
Comment: B, A), transfer family does not support EBS C,D), S3 has lower IOPS than EFS
Comment: Create an encrypted Amazon Elastic File System (Amazon EFS) volume. Create an AWS Transfer Family SFTP service with elastic IP addresses and a VPC endpoint that has internet-facing access. Attach a security group to the endpoint that allows only trusted IP addresses. Attach the EFS volume to the SFTP service endpoint. Grant users access to the SFTP service.
Comment: https://aws.amazon.com/blogs/storage/use-ip-whitelisting-to-secure-your-aws-transfer-for-sftp-servers/
Comment: EFS is best to serve this purpose.
Comment: Answer C (from abylead.com) Transfer Family offers fully managed serverless support for B2B file transfers via SFTP, AS2, FTPS, & FTP directly in & out of S3 or EFS. For a controlled internet access you can use internet-facing endpts with Transfer SFTP servers & restrict trusted internet sources with VPC's default Sgrp. In addition, S3 Access Points aliases allows you to use S3 bkt names for a unique access control plcy on shared S3 datasets. Transfer SFTP & S3: https://aws.amazon.com/blogs/apn/how-to-use-aws-transfer-family-to-replace-and-scale-sftp-servers/ A)Transfer SFTP doesn't support EBS, not for share data, & not serverless: infeasible. B)EFS mounts via ENIs not endpts: infeasible. D)pub endpt for internet access is missing: infeasible.
Comment: BBBBBBBBBBBBBB
Comment: EFS all day
Comment: https://aws.amazon.com/blogs/storage/use-ip-whitelisting-to-secure-your-aws-transfer-for-sftp-servers/ is worth a read
Comment: EFS is serverless. There is no reference in S3 about IOPS
Comment: Option D is incorrect because it suggests using an S3 bucket in a private subnet with a VPC endpoint, which may not meet the requirement of maintaining control over user permissions as effectively as the EFS-based solution.
Comment: It is D Refer https://docs.aws.amazon.com/transfer/latest/userguide/create-server-in-vpc.html for further details.
Comment: In D you create an "endpoint that has internal access in a private subnet", how to access that from the Internet?
Comment: asynchronous=SQS, microservices=ECS. Use AWS Auto Scaling to adjust the number of ECS services.
Comment: good breakdown :)
Comment: For once examtopic answer is correct :) haha... Batch requests/async = Amazon SQS Microservices = Amazon ECS Workload variations = AWS Auto Scaling on Amazon ECS
Comment: ALB is mentioned in other options to distract you, you dont need ALB for scaling here, we would need ECS autoscaling, they play with that idea in option B a bit however D gets it in a completely optimized way.... A and C both have lambda which for Machine learning models with workloads on heavy side, will not fly
Comment: I go with everyone D.
Comment: D, no need for an App Load balancer like C says, no where in the text. SQS is needed to ensure all request gets routed properly in a Microservices architecture and also that it waits until its picked up. ECS with Autoscaling, will scale based on the unknown pattern of usage as mentioned.
Comment: It is D Refer https://aws.amazon.com/blogs/containers/amazon-elastic-container-service-ecs-auto-scaling-using-custom-metrics/ for additional information/knowledge.
Comment: because it is scalable, reliable, and efficient. C does not scale the models automatically
Comment: why C doesn't scale the model? Application Auto Scaling can apply to lambda.
Comment: Auto Scaling doesn't apply to Lambda. As your functions receive more requests, Lambda automatically handles scaling the number of execution environments until you reach your account's concurrency limit.
Comment: How would you "use Auto Scaling (!) to increase the number of vCPUs (!) for the Lamba functions"?
Comment: identity-based policy used for role and group
Comment: Isn't the content of the policy completely irrelevant? IAM policies are applied to users, groups or roles ...
Comment: AB is correct, but the question is misleading because, according to the AWS IAM documentation, groups are not considered principals: https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html#intro-structure-principal."
Comment: A. Role B. Group
Comment: Role or group
Comment: Reserved+ spot . Fargate for serverless
Comment: Has to be A, It can scale down if required and you will be charged for what you use with fargate. Secondly they have not said the backend can have timeouts or can be down for a little period of time or something. So it has to rule out any spot instances even though they are cheaper.
Comment: Fargate is serverless EKS so it cannot manage EC2 nodes
Comment: I will go with A. Where does the question mentions that the workload interruptions are accepted.
Comment: B) because firegate is containser
Comment: so what ive make up from this scenario is: the key word right here is "backend nodes" you cant use a serverless compute service with nodes and you need to use EC2s so if we had ECS EC2 lunch type or on-demand EC2s as an options for the backend, they would be true?
Comment: 24-7 usage for fe -> reserved instance irregular workload for be -> spot instance
Comment: Not A because Fargate runs containers, not EC2 instances. But we have no indication that the workload would be containerized; it runs "on EC2 instances". Not C and D because frontend must run 24/7, can't use Spot. Thus B, yes, Spot instances are risky, but as they need to run "only for a short time" it seems acceptable. Technically ideal option would be Reserved Instances for frontend nodes and On-demand instances for backend nodes, but that is not an option here.
Comment: Not sure the application can be containerized
Comment: it is safe
Comment: Fargate = containers A is wrong
Comment: Reserved Instances (RIs) for Frontend Nodes: Since the frontend nodes need to run continuously (24/7), using Reserved Instances for them makes sense. RIs provide significant cost savings compared to On-Demand Instances for steady-state workloads. Spot Instances for Backend Nodes: Spot Instances are suitable for short-duration workloads and can be significantly cheaper than On-Demand Instances. Since the number of backend nodes varies during the day, Spot Instances can help you take advantage of spare capacity at a lower cost. Keep in mind that Spot Instances may be interrupted if the capacity is needed elsewhere, so they are best suited for stateless and fault-tolerant workloads.
Comment: Option A (Use Reserved Instances for the frontend nodes. Use AWS Fargate for the backend nodes): AWS Fargate is a serverless compute engine for containers, and it may not be the best fit for the described backend workload, especially if the number of backend nodes varies during the day.
Comment: AWS Fargate is a serverless compute engine for containers that allows you to run containers without having to manage the underlying infrastructure. It simplifies the process of deploying and managing containerized applications by abstracting away the complexities of server management, scaling, and cluster orchestration. No containerized application requirements are mentioned in the question. Plain EC2 instances. So Fargate is not actually an option
Comment: A is fargate, which is none sense. B seems more OK (though none-sense)
Comment: Fargate for backend node
Comment: Fargate is for containers not EC2 so A is wrong
Comment: (B) would take chance, though unlikely (A) is server-less auto-scaling. In case backend is idle, it might scale down, save money but no need to worry for interruption by Spot instance.
Comment: If you will use spot instances you must assumme lost any job in course. This scenary has not explicit mentions about aaplication can tolerate this situations, then, on my opinion, option A is the most suitable.
Comment: But the app is not containerized, it can't run on Fargate without significant changes.
Comment: Question keyword "scale out and scale in more instances". Therefore not related Kubernetes. Choose B, reserved instance for front-end and spot instance for back-end.
Comment: im on the fence for SPOT because you could lose your spot during a workload and it doesnt mention that, that is acceptable.. Business needs to define requirements and document acceptability for this or you lose your job..
Comment: Totally agree, lose job in course is an assumption for use spot instances and scenary has not explicit mentions about
Comment: But C and D are out because it would run the frontend on Spot instances, and A is out because the workload is not containerized.
Comment: Gp3 $ 0.08 usd per gb Gp2 $ 0.10 usd per gb
Comment: Both GP2 and GP3 has max IOPS 16000 but GP3 is cost effective. https://aws.amazon.com/blogs/storage/migrate-your-amazon-ebs-volumes-from-gp2-to-gp3-and-save-up-to-20-on-costs/
Comment: C. GP3 volume type
Comment: Quote "customers can scale up to 16,000 IOPS and" at https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-new-amazon-ebs-general-purpose-volumes-gp3/
Comment: The GP3 (General Purpose SSD) volume type in Amazon Elastic Block Store (EBS) is the most cost-effective option for the given requirements. GP3 volumes offer a balance of price and performance and are suitable for a wide range of workloads, including those with moderate I/O needs. GP3 volumes allow you to provision performance independently from storage capacity, which means you can adjust the baseline performance (measured in IOPS) and throughput (measured in MiB/s) separately from the volume size. This flexibility allows you to optimize your costs while meeting the workload requirements. In this case, since the company's daily peak input and output transactions per second are not more than 15,000 IOPS, GP3 volumes provide a suitable and cost-effective option for their workloads.
Comment: It is not C pals. The company wants to migrate the workloads to Amazon EC2 and to provision disk performance independent of storage capacity. With GP3 we have to increase storage capacity to increase IOPS over baseline. You can only chose IOPS independetly with IO family and IO2 is in general better then IO1.
Comment: @maver144 - That's the case with GP2 volumes. With GP3 we can define IOPS independent of storage capacity.
Comment: Therefore, the most suitable and cost-effective option in this scenario is the GP3 volume type (option C).
Comment: GPS3 allows 16000 IOPS
Comment: A is better because: - Data sync is used for migrate. Storage gw is used to connect on-prem to AWS. - dataevents is to log for access, management events is for config or management
Comment: We need to log "access at all levels" aka "data events", thus B and D are out (logging only "management events" like granting permissions or changing the access tier). C, S3 Transfer Acceleration is to increase upload performance from widespread sources or over unreliable networks, but it just provides an endpoint, it does not upload anything itself.
Comment: Typical DataSync scenario me thinks!
Comment: Use AWS DataSync to migrate existing data to Amazon S3https://aws.amazon.com/datasync/faqs/
Comment: It's DataSync for me
Comment: Storage Gateway integration with CloudTrail : https://docs.aws.amazon.com/filegateway/latest/filefsxw/logging-using-cloudtrail.html whereas DataSync can be monitored with Amazon CloudWatch: https://docs.aws.amazon.com/datasync/latest/userguide/monitor-datasync.html
Comment: and here are all Storage Gateway actions monitored by CloudTrail: https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_Operations.html
Comment: B and C don't solve the problem A is extending the data and management events are for administrative actions only (tracking account creation, user security actions etc.). C uses DataSync to move all the data and logs data events which include S3 file uploads and downloads. Management events: User logs into an EC2 instance, creates an S3 IAM role Data events: User uploads a file to S3
Comment: A- DataSync secure fast data transfer
Comment: *Keyword* of this question = running out of storage capacity AWS Storage Gateway = extend the on-premises storage AWS DataSync = copy data between on-premises storage So, the answer should be D (AWS Storage Gateway)
Comment: "Securely migrate the existing data to AWS" -> move data away fron on-premises storage to AWS. Plus, D logs only management events, not "access at all levels".
Comment: AWS DataSync is designed for fast, simple, and secure data transfer, but it focuses more on data synchronization rather than on-premises migration.
Comment: Thus it is wrong, but more because of the incorrect logging option in this answer.
Comment: AWS DataSync is suitable for data transfer and synchronization Option D (Use AWS Storage Gateway to move the existing data to Amazon S3. Use AWS CloudTrail to log management events): AWS Storage Gateway is typically used for hybrid cloud storage solutions and may introduce additional complexity for a one-time data migration task. It might not be as straightforward as using AWS Snowcone for this specific scenario.
Comment: both DataSync and Storage Gateway are fine to sync data...but to "audit access at all levels of the stored data" ...it should be data events(data plane operation)..management event is some account level things. So answer should be A
Comment: While both DataSync and Storage Gateway allow syncing of data between on-premise and cloud, DataSync is built for rapid shifting of data into a cloud environment, not specifically for continued use in on-premise servers.
Comment: AWS DataSync is an online data transfer service that simplifies, automates, and accelerates the process of copying large amounts of data to and from AWS storage services over the Internet or over AWS Direct Connect.
Comment: What about logging?
Comment: A seems to be more convincing to me.
Comment: tabbyDolly 1 month ago is right. Also Data Sync is designed for data changes.
Comment: The company hosts applications on on-premises infrastructure, so they should use a Storage Gateway solution.
Comment: What about logging requirements?
Comment: B AWS Elastic Beanstalk provides an easy and quick way to deploy, manage, and scale applications. It supports a variety of platforms, including Java and Apache Tomcat. By using Elastic Beanstalk, the solutions architect can upload the Java application and configure the environment to run Apache Tomcat.
Comment: Beanstalk for sure
Comment: By using Elastic Beanstalk, the solutions architect can upload the Java application and configure the environment to run Apache Tomcat.
Comment: The key word here from the question if you notice is "The Java application must be DEPLOYED..." hence Elastic Beanstalk, it is a serverless deployment service and supports a variety of platforms(apache Tomcat in our situation), and it will scale automatically with less operational overhead(unlike option D with a lot of operation overhead)
Comment: https://aws.amazon.com/elasticbeanstalk/details/
Comment: B. Deploy the application by using AWS Elastic Beanstalk. Configure a load-balanced environment and a rolling deployment policy.
Comment: Keyword "AWS Elastic Beanstalk" for re-architecture from Java web-app inside Apache Tomcat to AWS Cloud.
Comment: Definitely B
Comment: Clearly B.
Comment: Easy deploy, management and scale
Comment: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Comment: DynamoDB needs to trust Lambda. NOT the other way around. So Lambda must be configured as a trusted service. Role for service which gives B and D options. D is setting up (somehow?) to allow Lambda to trust DynamoDB... or the wording makes no sense.
Comment: Keyword B. " IAM role that includes Lambda as a trusted service", not "IAM role that includes DynamoDB as a trusted service" in D. It is IAM role, not IAM user.
Comment: IAM Role for access to DynamoDB, not for access Lambda
Comment: B sounds better.
Comment: BBBBBBBBBB
Comment: vote B
Comment: B Option B suggests creating an IAM role that includes Lambda as a trusted service, meaning the role is specifically designed for Lambda functions. The role should have a policy attached to it that grants the required read and write access to the DynamoDB table.
Comment: B is right Role key word and trusted service lambda
Comment: came in exam today
Comment: for the us-east-1 Region only, not for all region
Comment: One of the few situations when actual answer is same as the most voted answer lol
Comment: Not sure why everyone vote D, I think that the valid option as to be C as the second condition regarding MFA there is point that only refer to a specific region, so basically this means that is for all the regions
Comment: Ok ignore D is right as the first condition is what gives permission to make anything for EC2 but is restricted to us-east-1 region
Comment: the json is describing a lot of things apparently, so I go with the longest answer lol
Comment: D. Group members are allowed the ec2:StopInstances and ec2:TerminateInstances permissions for the us-east-1 Region only when logged in with multi-factor authentication (MFA). Group members are permitted any other Amazon EC2 action within the us-east-1 Region
Comment: A. "Statements after the Allow permission are not applied." --> Wrong. B. "denied any Amazon EC2 permissions in the us-east-1 Region" --> Wrong. Just deny 2 items. C. "allowed the ec2:StopInstances and ec2:TerminateInstances permissions for all Regions" --> Wrong. Just region us-east-1. D. ok.
Comment: Only D makes sense
Comment: D sounds about right.
Comment: D is correct
Comment: D is correct
Comment: D is right
Comment: B for processing the images via Lambda as it's more cost efficient than EC2 spot instances C for expiring images after 30 days and because the ML trainings are planned weeks in advance so S3 glacier is ideal for slow retrieval and cheap storage. D and E uses S3 infrequent access which is more expensive than glacier
Comment: Not A, we need the images "as soon as possible", A runs every hour "ML trainings and audits are planned weeks in advance" thus Glacier (C) is ok.
Comment: Answer is B&C. For D, you must store data for 30 days in s3 standard before move to IA tiers, glacier is fine https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#:~:text=Before%20you%20transition%20objects%20to%20S3%20Standard%2DIA%20or%20S3%20One%20Zone%2DIA%2C%20you%20must%20store%20them%20for%20at%20least%2030%20days%20in%20Amazon%20S3
Comment: Definitely B & C
Comment: A. Wrong, the .csv files must be processed asap. D and E are incorrect since Glacier is the most cost-effective option, and plans for using .csv files are known weeks in advance.
Comment: Why need "These .csv files must be converted into images"?
Comment: Because they are being used in some graphical reports (probably fancy powerpoint presentations!)
Comment: the key word is Weeks in advance, even you save data in S3 Gracia will also OK to take couples days to retrieve the data
Comment: Definitely B & C
Comment: A. Wrong because Lifecycle rule is not mentioned. B. CORRECT C. CORRECT D. Why Store on S3 One Zone-Infrequent Access (S3 One Zone-IA) when the files are going to irrelevant after 1 month? (Availability 99.99% - consider cost) E. again, Why use Reduced Redundancy Storage (RRS) when the files are irrelevant after 1 month? (Availability 99.99% - consider cost)
Comment: https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html
Comment: B: Serverless and fast responding E: will keep .csv file for a year, C and D expires the file after 30 days.
Comment: B&C, misread the question, expires the image files after 30 days.
Comment: https://aws.amazon.com/jp/about-aws/whats-new/2021/11/amazon-s3-glacier-storage-class-amazon-s3-glacier-flexible-retrieval/
Comment: B severless and cost effective C corrctl rule to store
Comment: Redis provides fast in-memory data storage and processing. It can compute the top 10 scores and update the cache in milliseconds. ElastiCache Redis supports sorting and ranking operations needed for the top 10 leaderboard. The cached leaderboard can be retrieved from Redis vs hitting the MySQL database for every read. This reduces load on the database. Redis supports persistence, so scores are preserved if the cache stops/restarts
Comment: Real-time gaming leaderboards are easy to create with Amazon ElastiCache for Redis. Just use the Redis Sorted Set data structure, which provides uniqueness of elements while maintaining the list sorted by their scores. Creating a real-time ranked list is as simple as updating a user's score each time it changes. You can also use Sorted Sets to handle time series data by using timestamps as the score. https://aws.amazon.com/elasticache/redis/#:~:text=ElastiCache%20for%20Redis.-,Gaming,-Leaderboards
Comment: ElastiCache for Redis sorts and ranks datasets
Comment: https://aws.amazon.com/blogs/database/building-a-real-time-gaming-leaderboard-with-amazon-elasticache-for-redis/
Comment: concurrently = memcached
Comment: Amazon ElastiCache for Memcached is non-persistent so start/stop of game will lose the score." and offer the ability to stop and restore the game while preserving the current scores."
Comment: See case study of leaderboard with Redis at https://redis.io/docs/data-types/sorted-sets/ , it is feature "sorted sets". See comparison between Redis an d Memcached at https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/SelectEngine.html , the different at feature "Sorted sets"
Comment: advanced data structures, complex querying, pub/sub messaging, or persistence, Redis may be a better fit.
Comment: B is correct
Comment: B correct.
Comment: https://aws.amazon.com/jp/blogs/news/building-a-real-time-gaming-leaderboard-with-amazon-elasticache-for-redis/
Comment: Amazon ElastiCache for Redis is a highly scalable and fully managed in-memory data store. It can be used to store and compute the scores in real time for the top-10 scoreboard. Redis supports sorted sets, which can be used to store the scores as well as perform efficient queries to retrieve the top scores. By utilizing ElastiCache for Redis, the web application can quickly retrieve the current scores without the need to perform complex and potentially resource-intensive database queries.
Comment: B is right
Comment: More questions!!!
Comment: https://docs.aws.amazon.com/quicksight/latest/user/sagemaker-integration.html
Comment: Machine Learning = Sage Maker so B for least operational overhead A and D are not right technologies. C is possible but with more overhead of using AMI even if you can get OpenSearch to visualize the data somehow which I don't think is possible without massive overhead
Comment: Use Amazon SageMaker to build and train models. Use Amazon QuickSight to visualize the data.
Comment: Question keyword "machine learning", answer keyword "Amazon SageMaker". Choose B. Use Amazon QuickSight for visualization. See "Gaining insights with machine learning (ML) in Amazon QuickSight" at https://docs.aws.amazon.com/quicksight/latest/user/making-data-driven-decisions-with-ml-in-quicksight.html
Comment: Sagemaker.
Comment: Business intelligence, visualiations = AmazonQuicksight ML = Amazon SageMaker
Comment: Most likely B.
Comment: Amazon SageMaker is a fully managed service that provides every developer and data scientist with the ability to build, train, and deploy ML models quickly.
Comment: Amazon SageMaker is a fully managed service that provides a complete set of tools and capabilities for building, training, and deploying ML models. It simplifies the end-to-end ML workflow and reduces operational overhead by handling infrastructure provisioning, model training, and deployment. To visualize the data and integrate it into business intelligence dashboards, Amazon QuickSight can be used. QuickSight is a cloud-native business intelligence service that allows users to easily create interactive visualizations, reports, and dashboards from various data sources, including the augmented data generated by the ML models.
Comment: ML== SageMaker
Comment: B sagemaker provide deploy ml models
Comment: Tip: AWS Organziaton + service control policy (SCP) - This for any questions, you see both together. then you tell me C. Create a service control policy (SCP) to prevent tag modification except by authorized principals.
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html AWS example for this question/use case: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin
Comment: D "Amazon CloudWatch" just for logging, not for prevent tag modification https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-cwe.html Amazon Organziaton has "Service Control Policy (SCP)" with "tag policy" https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html . Choose C. AWS Config for technical stuff, not for tag policies. Not A.
Comment: Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization.
Comment: Anytime we need to restrict anything in an AWS Organization, it is SCP Policies.
Comment: AWS Config is for tracking configuration changes
Comment: so it's wrong. Right asnwer is C
Comment: I'd say C.
Comment: https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html
Comment: Denies tag: modify
Comment: A and D is correct. But Route 53 haves a feature DNS failover when instances down so we dont need use Cloudwatch and lambda to trigger -> A correct
Comment: Yes it does but you configure it. Its not automated anymore. D is the best answer!
Comment: What are you talking about configuring ? Yes you have to configure everything at some point https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html
Comment: Did not see Route 53 in this question right? So my opinion is D
Comment: They are not asking for automatic failover, they want to "ensure the application can (!) be made available in another AWS Region with minimal downtime". This works with C; they would just execute the template and it would be available in short time. A would create a DR environment that IS already available, which is not what the question asks for. D is like A, just abusing Lambda to update the DNS record (which doesn't make sense). B would create a separate, empty database
Comment: ChatGPT: Option C involves creating an AWS CloudFormation template to create EC2 instances and a load balancer only when needed, and configuring the DynamoDB table as a global table. This approach might introduce more downtime because the infrastructure in the disaster recovery region is not pre-deployed and ready to take over immediately. The process of launching instances and configuring the load balancer can take some time, leading to delays during the failover. Option A, on the other hand, ensures that the necessary infrastructure (Auto Scaling group, load balancer, and DynamoDB global table) is already set up and running in the disaster recovery region. This pre-deployment reduces downtime since the failover can be handled quickly by updating DNS to point to the disaster recovery region's load balancer.
Comment: With the LEAST amount of downtime = A Cost effective = C , but risky some of EC2 types/capacity not available in Region at the time, when need to switch to DR
Comment: There are 2 parts. DB and application. Dynamo DB recovery in another region is not possible without global table so option B is out. A will make the infra available in 2 regions which is not required. The question is about DR, not scaling. D Use Lambda to modify R53 to point to new region. This is going to cause delays but is possible and it will also be running a scaled EC2 instances in passive region. C Make a CF template which can launch the infra when needed. DB is global table so it will be available.
Comment: AWS CloudFormation Template: Use CloudFormation to define the infrastructure components (EC2 instances, load balancer, etc.) in a template. This allows for consistent and repeatable infrastructure deployment. EC2 Instances and Load Balancer: Launch the EC2 instances and load balancer in the disaster recovery (DR) Region using the CloudFormation template. This enables the deployment of the application in the DR Region when needed. DynamoDB Global Table: Configure the DynamoDB table as a global table. DynamoDB Global Tables provide automatic multi-region, multi-master replication, ensuring that the data is available in both the primary and DR Regions. DNS Failover: Configure DNS failover to point to the new DR Region's load balancer. This allows for seamless failover of traffic to the DR Region when needed. Option A is close, but it introduces an Auto Scaling group in the disaster recovery Region, which might introduce unnecessary complexity and potential scaling delays. Option D introduces a Lambda function triggered by CloudWatch alarms, which might add latency and complexity compared to the more direct approach in Option C.
Comment: Assuming theyre using Route53 as a DNS then A https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Comment: Only B and C take care of EC2 instants. But since B does not take care of Data in the Dynamo DB, C is the only correct Answer.
Comment: Route 53 haves a feature DNS failover when instances down
Comment: C is the best choice here
Comment: I think CloudFormation is easier than manual provision of Auto Scaling group and load balancer in DR region.
Comment: Creating Auto Scaling group and load balancer in DR region allows fast launch of capacity when needed. Configuring DynamoDB as a global table provides continuous data replication. Using DNS failover via Route 53 to point to the DR region's load balancer enables rapid traffic shifting.
Comment: Both Option A and Option D include the necessary steps of setting up an Auto Scaling group and load balancer in the disaster recovery Region, configuring the DynamoDB table as a global table, and updating DNS records. However, Option D provides a more detailed approach by explicitly mentioning the use of an Amazon CloudWatch alarm and AWS Lambda function to automate the DNS update process. By leveraging an Amazon CloudWatch alarm, Option D allows for an automated failover mechanism. When triggered, the CloudWatch alarm can execute an AWS Lambda function, which in turn can update the DNS records in Amazon Route 53 to redirect traffic to the disaster recovery load balancer in the new Region. This automation helps reduce the potential for human error and further minimizes downtime. Answer is D
Comment: Failover policy takes care of DNS record update so no need for cloud watch/lambda
Comment: The company wants to ensure the application 'CAN' be made available in another AWS Region with minimal downtime. Meaning they want to be able to launch infra on need basis. Best answer is C.
Comment: minimal downtme not minimal effort! D
Comment: B, C are not OK because "launching resources when needed", which will increase the time to recover "DR"
Comment: I feel it is A Configure DNS failover: Use DNS failover to point the application's DNS record to the load balancer in the disaster recovery Region. DNS failover allows you to route traffic to the disaster recovery Region in case of a failure in the primary Region.
Comment: Once you configure manually the DNS , its no more automated like Lambda does.
Comment: C suits best
Comment: AがDNS フェイルオーバー
Comment: A) 300 first 10 days. 150 shipping D) 750 for 2 weeks
Comment: Thanks, i was checking the speed more than price. Thanks for the clarification
Comment: Direct Connect takes at least 1 month to setup - D is invalid AWS Snowmobile is used for transferring large amounts of data (petabytes) from remote locations where establishing a connection to the cloud is impossible - B is invalid AWS Snowball Edge Compute Optimized provides higher vCPU performance and lower storage as compared to Snowball storage optimized. As our need is solely data transfer, high vCPU performance is not required but high storage is - C is invalid
Comment: But I didn't understand why we are using a schema conversion tool, because AWS have already a managed service engine for MySQL Db, (RDS for MySQL or Aurora for my SQL is on the table )
Comment: To calculate the time it would take to transfer 20TB of data over a 1 GB dedicated AWS Direct Connect, we can use the formula: time = data size / data transfer rate Here, the data size is 20TB, which is equivalent to 20,000 GB or 20,000,000 MB. The data transfer rate is 1 GB/s. Converting the data size to MB, we get: 20,000,000 MB / 1 GB/s = 20,000 seconds Therefore, it would take approximately 20,000 seconds or 5.56 hours to transfer 20TB of data over a 1 GB dedicated AWS Direct Connect.
Comment: It takes more way more than 2 weeks to setup Direct Connect. Therefore, D is not valid since we have to do the transfer within 2 weeks.
Comment: C is wrong, GPU is not needed
Comment: Has to be A. the option for D would only work if they said they have like 6 Months plus. It would take too long to set up.
Comment: I agreed with A. Why not D.? When you initiate the process by requesting an AWS Direct Connect connection, it typically starts with the AWS Direct Connect provider. This provider may need to coordinate with AWS to allocate the necessary resources. This initial setup phase can take anywhere from a few days to a couple of weeks. Couple of weeks? No Good
Comment: When you create a Snowball job in the AWS console, it will estimate the delivery date based on your location. Being near a facility shows 1-2 day estimated delivery. For extremely urgent requests, you can contact AWS Support and inquire about expedited Snowball delivery. If inventory is available, they may be able to ship same day or next day.
Comment: Keyword "20 TB", choose "AWS Snowball", there are A or C. C has word "GPU" what is not related, therefore choose A.
Comment: Answer A
Comment: D is correct
Comment: No, takes months, not weeks
Comment: https://docs.aws.amazon.com/dms/latest/userguide/CHAP_LargeDBs.Process.html
Comment: D Direct Connection will need a long time to setup plus need to deal with Network and Security changes with existing environment. Ad then plus the Data trans time... No way can be done in 2 weeks.
Comment: Overall, option D combines the reliability and cost-effectiveness of AWS Direct Connect, AWS DMS, and AWS SCT to migrate the database efficiently and minimize downtime.
Comment: D - Direct Connect takes atleast a month to setup! Requirement is for within 2 weeks.
Comment: AWS Snowball Edge Storage Optimized device is used for large-scale data transfers, but the lead time for delivery, data transfer, and return shipping would likely exceed the 2-week time frame. Also, ongoing database changes wouldn't be replicated while the device is in transit.
Comment: Change to A because "Most cost effective"
Comment: https://docs.aws.amazon.com/ja_jp/snowball/latest/developer-guide/device-differences.html#device-options Aです。
Comment: How long does direct connect take to provision ?
Comment: At least one month and expensive.
Comment: A. "without adding infrastructure" means scaling vertically and choosing larger instance. "MOST cost-effectively" reserved instances
Comment: "MOST cost-effectively" doesn't mean reserved instances. Only in this case it is but not in general.
Comment: accommodate the larger workload without adding infrastructure. = Reserved DB instance
Comment: + make the instance larger so most cost effective is to reserve a large instance suitable for workload which is A
Comment: B - Multi-AZ is for HA, does not help 'accommodating the larger workload' C - Adding "another instance" will not help, we can't split the workload between two instances D - On-demand instance is a good choice for unknown workload, but here we know the workload, it's just higher than before
Comment: Cannot add more infrastructure - C is invalid Multi AZ DB instance is for high availability and failure mitigation, does not increase performance, higher workload support - B is invalid On demand instances are costlier than Reserved instances - D is invalid
Comment: Not A : "launched a new product", reserved instances are for known workloads, a new product doesn't have known workload. Not B : "accommodate the larger workload", while Multi-AZ can help with larger workloads, they are more for higher availability. Not C : "without adding infrastructure", adding a PostGresQL instance is new infrastructure.
Comment: Question says nothing about unknown load. New product -> more total products -> load has increased.
Comment: B is the best approach in this scenario overall: Making the RDS PostgreSQL instance Multi-AZ adds a standby replica to handle larger workloads and provides high availability. Even though it adds infrastructure, the cost is less than doubling the infrastructure with a separate DB instance. It provides better performance, availability, and disaster recovery than a single larger instance.
Comment: Agreed the answer is B Multi-AZ deployments are cost-effective because they leverage the standby instance without incurring additional charges. You only pay for the primary instance's regular usage costs.
Comment: Multi-AZ is for HA, does not add performance. Meaning, will not help 'accommodating the larger workload'.
Comment: Buy larger instance.
Comment: Keyword "Amazon RDS for PostgreSQL instance large" . See list of size of instance at https://aws.amazon.com/rds/instance-types/
Comment: A. Not C: without adding infrastructure
Comment: Answer - C Option B, making the Amazon RDS for PostgreSQL DB instance a Multi-AZ DB instance, would provide high availability and fault tolerance but may not directly address the need for increased capacity to handle the larger workload. Therefore, the recommended solution is Option C: Buy reserved DB instances for the workload and add another Amazon RDS for PostgreSQL DB instance to accommodate the increased workload in a cost-effective manner.
Comment: C Option C: buying reserved DB instances for the total workload and adding another Amazon RDS for PostgreSQL DB instance seems to be the most appropriate choice. It allows for workload distribution across multiple instances, providing scalability and potential performance improvements. Additionally, reserved instances can provide cost savings in the long term.
Comment: A for me, because without adding additional infrastructure
Comment: Should be C
Comment: That would add more infraestructure. A would increase the size, keeping the number of instances, i think
Comment: Option A involves making the existing Amazon RDS for PostgreSQL DB instance larger. While this can improve performance, it may not be sufficient to handle a significantly increased workload. It also doesn't distribute the workload or provide scalability.
Comment: The main not HA, cost-effectively and without adding infrastructure
Comment: A is the best
Comment: As no shield protect here so WAF rate limit
Comment: Where's your Shield Advanced now, in your hour of need he has abandoned you
Comment: Best solution Shield Advanced, not listed here, thus second-best solution, WAF with rate limiting
Comment: A. Amazon Inspector = Software vulnerabilities like OS patches etc. Not fit for purpose. C. Changing IP from DDoS so don't know the incoming traffic for configuration (even if it was possible) D. GardDuty is for workload and AWS account monitoring so it can't help with DDoS. B is correct as AWS WAF + ALB can configure rate limiting even if source IP changes.
Comment: according to some google searches... to protect against DDOS attack: * AWS WAF(Web Application Firewall) provides protection on the application layer (I think Application Load Balancer belongs to this level) * AWS Shield protects the infrastructure layers of the OSI mode (I think AWS Network Load Balancer belongs to this level)
Comment: This case is A
Comment: Inspector is for detecting vulnerabilities, has nothing to do with the requirement.
Comment: AWS Web Application Firewall (WAF) + ALB (Application Load Balancer) See image at https://aws.amazon.com/waf/ . https://docs.aws.amazon.com/waf/latest/developerguide/ddos-responding.html . Question keyword "high request rate", answer keyword "rate-limiting rule" https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-example-limit-login-page-keys.html Amazon GuardDuty for theat detection https://aws.amazon.com/guardduty/ , not for DDoS.
Comment: B in swahili 'ba' :) external systems, incoming requests = AWS WAF
Comment: layer 7 DDoS protection with WAF https://docs.aws.amazon.com/waf/latest/developerguide/ddos-get-started-web-acl-rbr.html
Comment: B no doubt.
Comment: AWS WAF (Web Application Firewall) is a service that provides protection for web applications against common web exploits. By associating AWS WAF with the Application Load Balancer (ALB), you can inspect incoming traffic and define rules to allow or block requests based on various criteria.
Comment: B AWS Web Application Firewall (WAF) is a service that helps protect web applications from common web exploits and provides advanced security features. By deploying AWS WAF and associating it with the ALB, the company can set up rules to filter and block incoming requests based on specific criteria, such as IP addresses. In this scenario, the company is facing performance issues due to a high request rate from illegitimate external systems with changing IP addresses. By configuring a rate-limiting rule in AWS WAF, the company can restrict the number of requests coming from each IP address, preventing excessive traffic from overwhelming the website. This will help mitigate the impact of potential DDoS attacks and ensure that legitimate users can access the site without interruption.
Comment: If not AWS Shield, then WAF
Comment: B obv for this
Comment: My mind slipped with AWS Shield. GuardDuty can be working along with WAF for DDOS attack, but ultimately would be WAF https://aws.amazon.com/blogs/security/how-to-use-amazon-guardduty-and-aws-web-application-firewall-to-automatically-block-suspicious-hosts/
Comment: Same here, I was looking for AWS Shield
Comment: D, Guard Duty for me
Comment: Guard Duty detects threats, has nothing to do with rate-limiting.
Comment: The most secure way for the company to share the database with the auditor is option D: Create an encrypted snapshot of the database, share the snapshot with the auditor, and allow access to the AWS Key Management Service (AWS KMS) encryption key. By creating an encrypted snapshot, the company ensures that the database data is protected at rest. Sharing the encrypted snapshot with the auditor allows them to have their own copy of the database securely. In addition, granting access to the AWS KMS encryption key ensures that the auditor has the necessary permissions to decrypt and access the encrypted snapshot. This allows the auditor to restore the snapshot and access the data securely. This approach provides both data protection and access control, ensuring that the database is securely shared with the auditor while maintaining the confidentiality and integrity of the data.
Comment: best explanation ever
Comment: why not A ?
Comment: Encrypted snapshot must be most secure compare others
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html With AWS RDS, you can share snapshots across accounts so no need to go through S3 or replication. Option D allows more secure way by using encryption and sharing encryption key.
Comment: MOST secure way
Comment: Key word: "Secure way" The snapshot contents are encrypted using KMS keys for data security. Sharing the snapshot directly removes risks of extracting/transferring data. The auditor can restore the snapshot into their own RDS instance. Access is controlled through sharing the encrypted snapshot and KMS key.
Comment: Most likely D.
Comment: Option D (Creating an encrypted snapshot of the database, sharing the snapshot, and allowing access to the AWS Key Management Service encryption key) is generally considered a better option for sharing the database with the auditor in terms of security and control.
Comment: D for me
Comment: A is correct: You assign a single CIDR IP address range as the primary CIDR block when you create a VPC and can add up to four secondary CIDR blocks after creation of the VPC.
Comment: best option
Comment: A: LEAST operational overhead is by creating a new CIDR block in existing VPC. All other options require additional overhead of gateway or second VPC
Comment: After you've created your VPC, you can associate additional IPv4 CIDR blocks with the VPC
Comment: the architect just needs to: Add the CIDR using the AWS console or CLI Create new subnets in the VPC using the new CIDR Launch resources in the new subnets
Comment: A is best
Comment: Add additional CIDR of bigger range
Comment: Add new bigger subnets
Comment: A valid
Comment: C: Cost effective static content scaling = CloudFront A and B scale instances so not the best use of money for static content D Probably most expensive way of service static content at scale as you'll be charged for Lambda execution also
Comment: static content -> CloudFront
Comment: implementing CloudFront to serve static content is the most cost-optimal architectural change for this use case.
Comment: Keyword "Amazon CloudFront", "high volumes of static web content", choose C.
Comment: static web content = Amazon CloudFront
Comment: Static Web Content = S3 Always. CloudFront = Closer to the users locations since it will cache in the Edge nodes.
Comment: By leveraging Amazon CloudFront, you can cache and serve the static web content from edge locations worldwide, reducing the load on your EC2 instances. This can help lower the number of On-Demand Instances required to handle high volumes of static web content requests. Storing the static content in an Amazon S3 bucket and using CloudFront as a content delivery network (CDN) improves performance and reduces costs by reducing the load on your EC2 instances.
Comment: Static content, cloudFront plus S3
Comment: c for me
Comment: By utilizing Lake Formation's tag-based access control, you can define tags and tag-based policies to grant selective access to the required data for the engineering team accounts. This approach allows you to control access at a granular level without the need to copy or move the data to a common account or manage permissions individually in each account. It provides a centralized and scalable solution for securely sharing data across accounts with minimal operational overhead.
Comment: (B) uses the CLI command that has many options: principal, TableName, ColumnNames, LFTag etc providing a way to manage granular access permissions for different users at the table and column level. That way you don't give full access to the all the data. The problem with (B) is to implement this in each account has a lot more operational overhead than (D).
Comment: D: Selective data = tagging A and B gives full access to all the data C is possible but with complex operational overhead as you have to publish your data to the Data Exchange. (this is based on my limited knowledge so happy to be corrected)
Comment: D is the correct option with the least operational overhead. Using Lake Formation tag-based access control allows granting cross-account permissions to access data in other accounts based on tags, without having to copy data or configure individual permissions in each account. This provides a centralized, tag-based way to share selective data across accounts to authorized users with least operational overhead.
Comment: https://aws.amazon.com/blogs/big-data/securely-share-your-data-across-aws-accounts-using-aws-lake-formation/
Comment: The question asks for "a cost-effective solution [ONLY TO] to minimize upload and download latency and maximize performance", not for the actual application. And the 'cost-effective solution to minimize upload and download latency and maximize performance' is S3 Transfer Acceleration. Obviously there is more required to host the app, but that is not asked for.
Comment: The question is focused on large downloads and uploads. S3 Transfer Acceleration is what fits. CloudFront is for caching which cannot be used when the data is unique. They aren't as concerned with regular web traffic. Amazon S3 Transfer Acceleration can speed up content transfers to and from Amazon S3 by as much as 50-500% for long-distance transfer of larger objects.
Comment: A for sure
Comment: Not C, D No requirements to scale the application itself so EC2 is not applicable. B is for caching so not sure how/if that helps the upload speed for global users A is correct as Transfer Accelerator is best for uploading and downloading unique items near the user's region/location
Comment: for datas greater tham 1 GB, s3 transfer acceleration is the best
Comment: Application users will be able to download and upload UNIQUE data up to gigabytes in size Thus all caching related solution dont work.
Comment: Downloading data upto gigabytes in size - Cloudfront is a content delivery service that acts as an edge caching layer for images and other data. Not a service that minimizes upload and download latency.
Comment: The question is focused on large downloads and uploads. S3 Transfer Acceleration is what fits. CloudFront is for caching which cannot be used when the data is unique. They aren't as concerned with regular web traffic. C didn't mention S3. Where the data is stored?
Comment: A doesn't mention EC2 or EKS or ECS or Elastic Beanstalk or Lambda. Where does the "scalable web application" run?
Comment: It is A. https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html
Comment: It is A as the Transfer Acceleration will minimize upload and download latency. If you choose C, where would the files be stored? There is no mention of any S3. Will it be stored inside the EC2? That's why I didn't go for C
Comment: Amazon S3 with Transfer Acceleration (option A) is designed for speeding up uploads to Amazon S3, and it's not used for hosting scalable web applications. It doesn't mention using EC2 instances for hosting the application.
Comment: My answer is C
Comment: C because A is for upload data to S3, not for web app
Comment: The correct answer is C!!! It is not A, because - Amazon S3 with Transfer Acceleration (option A) is designed for speeding up uploads to Amazon S3, and it's not used for hosting scalable web applications. It doesn't mention using EC2 instances for hosting the application.
Comment: Amazon CloudFront is a global content delivery network (CDN) that delivers web content to users with low latency and high transfer speeds. It does this by caching content at edge locations around the world, which are closer to the users than the origin server. By using Amazon EC2 with Auto Scaling and Amazon CloudFront, the company can create a scalable and high-performance web application that is accessible to users from different geographic regions of the world.
Comment: I believe it would be A - my thinking maybe wrong but im just thinking specifically about the S3 put allows upto 5gb not sure about cloudfront. Second way of thinking is that cached content on edge locations but would it not have to go to source still to retrieve if another person wants to download that content in a different part of the world?
Comment: C, 1. Cloudfront cache data at edge, which provide better performance for read. Global Accelerator will always goto origin for content. 2. Cloudfront can also help performance for dynamic content, which is good for Web app
Comment: Option E: Sack the employee who did this :)
Comment: A: delete one instance, why?. Although takes care of reliability of DB instance however not EC2. B. seems perfect as takes care of reliability of both EC2 as well as DB C. DB instance's reliability is not taken care of D. seems to be trying to address cost alongside reliability of EC2 and DB.
Comment: A: Deleting one EC2 instance makes no sense. Why would you do that? C: API Gateway, Lambda etc are all nice but they don't solve the problem of DB instance deletion D: EC2 subnet blah blah, what? The problem is reliability, not networking! B is correct as it solves the DB deletion issue and increases reliability by Multi AZ scaling of EC2 instances
Comment: The key points: ° RDS Multi-AZ and deletion protection provide high availability for the database. ° The load balancer and Auto Scaling group across AZs give high availability for EC2. ° Options A, C, D have limitations that would reduce reliability vs option B.
Comment: Update the DB instance to be Multi-AZ, and enable deletion protection. Place the EC2 instances behind an Application Load Balancer, and run them in an EC2 Auto Scaling group across multiple Availability Zones
Comment: B for sure.
Comment: It is the only one with High Availability. Amazon RDS with Multi AZ EC2 with Auto Scaling Group in Multi Az
Comment: same question from https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c02/ long time ago and still same option B
Comment: B is correct. HA ensured by DB in Mutli-AZ and EC2 in AG
Comment: For those who wonders why not B. Snowball Edge Storage Optimized device for data transfer is up to 100TB https://docs.aws.amazon.com/snowball/latest/developer-guide/device-differences.html
Comment: The question explicitly mentioned "devices", also Snowball Edge Storage Optimized is 80TB HDD. So it is possible, but the answer is A because we can transfer with DataSync in 6.5 days.
Comment: 10GBs * 24*60*60 =864,000 GB estimate around 864 TB a day, 2 days will transfer all data. But for snowball at least 4 days for delivery to the data center.
Comment: This account is wrong but I get your point. It is wrong cause 10Gb/s is not the same as 10GB/s (Gigabits vs Gigabytes). However, the correct count is 864Tb/8 = 108TB per day. In one week you should've transferred all the data.
Comment: That's right, 1 GB = 8 Gb. Essentially we have a speed of 1.25GB/s.
Comment: Access during the transfer window -> DataSync
Comment: Finally, a company with good bandwidth.
Comment: (B) is incorrect bc although Mountpoint for S3 is possible for on-premises NAS, this is not as efficient as AWS DataSync. Data updates made during the transfer window would have to be resolved later.
Comment: I will put simple calculation for oyu guys to just store in your head to quickly answer: for 10GBPS its 1.25GBPS becasue its bits to bytes. for one minute its 75GBPS for one hour its 4500 GBPS for one day its 10.8 TB so you can calculate easily if you just store these numbers in your head. lets say if question is 1GBPS DirectConnect that meand everything above should be divide by 8. cool
Comment: Critical requirement: "The company needs to move the data efficiently and without disruption." B: Causes disruption C: I don't think that is possible without a gateway kind of thing D: Tape backups? " Mount a target Amazon S3 bucket on the on-premises file system"? This requires some gateway which is not mentioned A is the answer as DataSync allows transfer without disruption and with 10Gbps, it can be done in 90 days.
Comment: AWS DataSync can efficiently transfer large datasets from on-premises NAS to Amazon S3 over Direct Connect. DataSync allows accessing and updating the data continuously during the transfer process.
Comment: AWS DataSync is a secure, online service that automates and accelerates moving data between on premises and AWS Storage services.
Comment: A https://www.examtopics.com/discussions/amazon/view/46492-exam-aws-certified-solutions-architect-associate-saa-c02/#:~:text=Exam%20question%20from,Question%20%23%3A%20385
Comment: By leveraging AWS DataSync in combination with AWS Direct Connect, the company can efficiently and securely transfer its 700 terabytes of data to an Amazon S3 bucket without disruption. The solution allows continued access and updates to the data during the transfer window, ensuring business continuity throughout the migration process.
Comment: A for me, bcs egde storage up to 100tb
Comment: THIS WAS IN MY EXAM
Comment: Did you pass?
Comment: D as S3 batch operations reduce risk and manual copy/paste overhead.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Comment: A: Versioning, not relevant B: Governance, it won't enforce object lock C: Recopy existing objects may work but lots of operational overhead (see link) D: Compliance on existing objects with batch operations is least operational overhead https://repost.aws/questions/QUGKrl8XRLTEeuIzUHq0Ikew/s3-object-lock-on-existing-s3-objects
Comment: With option C, you have to copy the object for it to be complaint and then delete the original as only the new copy will be compliant. So D is the only option
Comment: To enable Object Lock on an Amazon S3 bucket, you must first enable versioning on that bucket. other 3 option did not enable versioning first
Comment: Recopying offers more control but requires users to manage the process. S3 Batch Operations automates the process at scale but with less granular control - LEAST operational overhead
Comment: Its C because you only need to recopy all existing objects one time, so why use S3 batch operations if new datas going to be in compliance retention mode? I can see why its C although my initial gut answer was D.
Comment: What if I don't have the original files anymore? Where should I copy them from?
Comment: You can only enable Object Lock for new buckets. If you want to turn on Object Lock for an existing bucket, contact AWS Support.
Comment: You need a token from AWS Support, but you CAN enable Object Lock for an existing bucket.
Comment: Turn on S3 Object Lock with compliance retention mode for the S3 bucket. Set the retention period to expire after 7 years. Use S3 Batch Operations to bring the existing data into compliance.
Comment: To replicate existing object/data in S3 Bucket to bring them to compliance, optionally we use "S3 Batch Replication", so option D is the most appropriate, especially if we have big data in S3.
Comment: For minimum ops D is best
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops-retention-date.html
Comment: Batch operations will add operational overhead.
Comment: And gathering all the files for copying them again does not?
Comment: Use Object Lock in Compliance mode. Then Use Batch operation. WRONG>>manual work and not automated>>>Recopy all existing objects to bring the existing data into compliance.
Comment: Batch IS automated. You just need to create the batch which is a one-time operation. "Recopy all existing objects" is not operational overhead?
Comment: C When an object is locked in compliance mode, its retention mode can't be changed, and its retention period can't be shortened. Compliance mode helps ensure that an object version can't be overwritten or deleted for the duration of the retention period.
Comment: error i meant to type D i wont do recopy
Comment: No, D for me because the requirement is LEAST operational overhead So RECOPy .......... is the manual operation -> C is wrong D is correct
Comment: Recopying vs. S3 Batch Operations: In Option C, the recommendation is to recopy all existing objects to ensure they have the appropriate retention settings. This can be done using simple S3 copy operations. On the other hand, Option D suggests using S3 Batch Operations, which is a more advanced feature and may require additional configuration and management. S3 Batch Operations can be beneficial if you have a massive number of objects and need to perform complex operations, but it might introduce more overhead for this specific use case. Operational complexity: Option C has a straightforward process of recopying existing objects. It is a well-known operation in S3 and doesn't require additional setup or management. Option D introduces the need to set up and configure S3 Batch Operations, which can involve creating job definitions, specifying job parameters, and monitoring the progress of batch operations. This additional complexity may increase the operational overhead.
Comment: You need AWS Batch to re-apply certain config to files that were already in S3, like encryption
Comment: Global, Reduce latency, health checks, no failover = Amazon CloudFront Global ,Reduce latency, health checks, failover, Route traffic = Amazon Route 53 option A has more weight.
Comment: Cloud front does have failover capabilities. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#:~:text=the%20secondary%20origin.-,Note,Choose%20Create%20origin%20group.
Comment: nicley explained
Comment: A. I'm not an expert in this area, but I still want to express my opinion. After carefully reviewing the question and thinking about it for a long time, I actually don't know the reason. As I mentioned at the beginning, I'm not an expert in this field.
Comment: All the explanation you need for this question and option A is in this article: https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/
Comment: Correct me if I'm wrong but CloudFront DOES NOT have health check capabilities out of the box. Route 53 and Global Accelerator do.
Comment: A for sure
Comment: B: Caching solution. Not ideal for failover although it will work. Would have been a correct answer if A wasn't an option C: Transit gateway is for VPC connectivity not AWS API or Lambda D: Even if it was possible, there is a primary region dependency of ALB A: correct because R53 health checks can failover across regions Good explanation here: https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/
Comment: The article also explains why you cannot use a CloudFront distribution for API Gateway, Lambda for failover
Comment: we can set primary and secondry regions in cloud front for failover.
Comment: Application is serverless, it doesn't matter where it runs, so can be active-active setup and run wherever the request comes in. Route 53 with health checks will route to a healthy region. B, could work too, but CloudFront is for caching which does not seem to help with an API. The goal here is "failover capabilities", not caching/performance/latency etc.
Comment: In activ active failover config, route53 continuously monitors its endpoints and if one of them is unhealthy, it excludes the region/endpoint from its valid traffic route - Only Sensible option Cloudfront is a content delivery network - not used to route traffic Transit gateway for traffic routing - aws devs will hit us with a stick on hearing this option You cant use a load balancer for cross region load balancing - invalid
Comment: Global ,Reduce latency, health checks, failover, Route traffic = Amazon Route 53
Comment: "What the?" yeah I know right
Comment: "Stateless applications provide one service or function and use content delivery network (CDN), web, or print servers to process these short-term requests. https://docs.aws.amazon.com/architecture-diagrams/latest/multi-region-api-gateway-with-cloudfront/multi-region-api-gateway-with-cloudfront.html
Comment: its not static content, actually they deployed a API Gateway backed by lambda
Comment: A option does make sense.
Comment: By creating an Amazon CloudFront distribution with origins in each AWS Region where the application is deployed, you can leverage CloudFront's global edge network to route traffic to the closest available Region. CloudFront will automatically route the traffic based on the client's location and the health of the origins using CloudFront health checks. Option A (creating Amazon Route 53 health checks with an active-active failover configuration) is not suitable for this scenario as it is primarily used for failover between different endpoints within the same Region, rather than routing traffic to different Regions.
Comment: Option A does not speak of Route 53 failover routing policies.
Comment: https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/
Comment: that is from 2017.. i wonder if it is still relevant..
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Comment: I understand that you can use Route 53 to provide regional failover.
Comment: To route traffic to multiple AWS Regions and provide regional failover capabilities for a stateless web application running on AWS Lambda functions invoked by Amazon API Gateway, you can use Amazon Route 53 with an active-active failover configuration. By creating Amazon Route 53 health checks for each Region and configuring an active-active failover configuration, Route 53 can monitor the health of the endpoints in each Region and route traffic to healthy endpoints. In the event of a failure in one Region, Route 53 automatically routes traffic to the healthy endpoints in other Regions. This setup ensures high availability and failover capabilities for your web application across multiple AWS Regions.
Comment: C is the correct option to mitigate the single point of failure. The Management VPC currently has a single VPN connection through one customer gateway device. This is a single point of failure. Adding a second set of VPN connections from the Management VPC to a second customer gateway device provides redundancy and eliminates this single point of failure.
Comment: As @Abrar2022 explains (production) VPN 1--------------> cgw 1 (management) VPN 2--------------> cgw
Comment: (production) VPN 1--------------> cgw 1 (management) VPN 2--------------> cgw 2
Comment: ANSWER IS C
Comment: C, (production) --PrivateGateway-------->Direct Connect Gateway 1 ---> cgw 1 ---> DataCenter (production) -- PrivateGateway ------> Direct Connect Gateway 2 --->cgw 2 --> DataCenter (Management) -- > VPN ---- > (Direct Connect Gateway 1?) --- >cgw1 ---> dataCenter---> device in dataCenter
Comment: I agree to C
Comment: option D is not a valid solution for mitigating single points of failure in the architecture. I apologize for the confusion caused by the incorrect information. To mitigate single points of failure in the architecture, you can consider implementing option C: adding a second set of VPNs to the Management VPC from a second customer gateway device. This will introduce redundancy at the VPN connection level for the Management VPC, ensuring that if one customer gateway or VPN connection fails, the other connection can still provide connectivity to the data center.
Comment: Redundant VPN connections: Instead of relying on a single device in the data center, the Management VPC should have redundant VPN connections established through multiple customer gateways. This will ensure high availability and fault tolerance in case one of the VPN connections or customer gateways fails.
Comment: https://www.examtopics.com/discussions/amazon/view/53908-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Key constraints: Limited resources for DB admin and cost. 3rd party db features with privileged access. A: Won't work due to 3rd party features C: AMI with Oracle may work but again overhead of backed, maintenance etc D: Too much overhead in rewrite B: Actually supports Oracle 3rd party features Caution: If this is only about APEX as suggested in option D, then A is also a possible answer: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.APEX.html
Comment: Action ignore the last line of my previous comment, A is not a valid option in any case as it suggest replacing 3rd party features with cloud services which is not possible without more details.
Comment: "Amazon RDS Custom is a managed database service for applications that require customization of the underlying operating system and database environment. Benefits of RDS automation with the access needed for legacy, packaged, and custom applications." That should allow the "privileged access".
Comment: Migrate the database to Amazon RDS Custom for Oracle. Customize the database settings to support third-party features.
Comment: Custom database features = Amazon RDS Custom for Oracle
Comment: Most likely B.
Comment: RDS Custom since it's related to 3rd vendor RDS Custom since it's related to 3rd vendor RDS Custom since it's related to 3rd vendor
Comment: CCCCCCCCCCCCCCCCCCCCC
Comment: https://aws.amazon.com/about-aws/whats-new/2021/10/amazon-rds-custom-oracle/
Comment: https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Resources.html
Comment: Amazon RDS Custom for Oracle, which is not an actual service. !!!!
Comment: Option C is also a valid solution, but it is not as cost-effective as option B. Option C requires the company to manage its own database infrastructure, which can be expensive and time-consuming. Additionally, the company will need to purchase and maintain Oracle licenses.
Comment: RDS Custom enables the capability to access the underlying database and OS so as to configure additional settings to support 3rd party. This feature is applicable only for Oracle and Postgresql
Comment: Sorry Oracle and sql server (not posstgresql)
Comment: I will say C cos of this "application uses third-party "
Comment: Should not it be since for Ec2, the company will have full control over the database and this is the reason that they are moving to AWS in the first place "The company plans to quickly migrate to AWS because of limited resources for the database, backup administration, and data center maintenance?"
Comment: "Amazon RDS Custom (B) is a managed database service for applications that require customization of the underlying operating system and database environment. Benefits of RDS automation with the access needed for legacy, packaged, and custom applications."
Comment: RDS Custom when is something related to 3rd vendor, for me
Comment: not sure, but b probably
Comment: The wording on this question makes things ambiguous for C. But, remember well-architected so: A: Not ideal as it is suggesting using existing architecture but with autoscaling EC2. Doesn't leave room for improvement on scaling or reliability on each tier. B: Single RDS, not well-architected D: Again, single RDS E,F are good options and C is only remaining good one.
Comment: C is badly worded IMHO because of this part " Refactor the application to host the web tier, application tier, and database tier." The database tier tier just makes it confusing when you don't read E and F.
Comment: C-scalable and resilient E-high availability of the application F-Multi-AZ configuration provides high availability
Comment: remove singles and remove network ACLs
Comment: i would flag this on the test and do it last.
Comment: option A cannot be the answer as Security group is at instance level whereas a NACL is at the subnet level. Having said that option C is the right one as the VPC cannot span across the regions and here it is mentioned two AZs for which I am guessing it is a default VPC which is created in each region with a subnet in each AZ.
Comment: So, CEF is the right answer
Comment: How can you create a VPC across 2 AZ? i only see EF here.. if they mean 2 separate VPC then that is different but a VPC cannot span two AZ..
Comment: A VPC most definitely can span across 2 AZ. You may be thinking of subnets.
Comment: I also agree with CEF but chatGPT answer is ACE. A and C is the similar Another Logic F is not True because in the question not mentioned about DB
Comment: ChatGPT is a language parser. It is not an AWS solution architect!
Comment: CEF is best
Comment: It's clearly CEF.
Comment: B- to control access to database C-scalable and resilient E-high availability of the application
Comment: CEF A: application's existing architecture is wrong (single AZ) B: single AZ D: Single AZ
Comment: C. This solution follows the recommended architecture pattern of separating the web, application, and database tiers into different subnets. It provides better security, scalability, and fault tolerance. E.By using Elastic Load Balancers (ELBs), you can distribute traffic to multiple instances of the web tier, increasing scalability and availability. Controlling access through security groups allows for fine-grained control and ensures only authorized traffic reaches each layer. F. Deploying an Amazon RDS database in a Multi-AZ configuration provides high availability and automatic failover. Placing the database in private subnets enhances security. Allowing database access only from the application tier security groups limits exposure and follows the principle of least privilege.
Comment: good explanation
Comment: Only this valid for best practices and well architected
Comment: ADE = AWS responsibility
Comment: Just to clarify on F. Direct Connect is an ISP and AWS offering, I consider it as a physical connection just like you get from your ISP at home. There is not security on it until you build security on the connection. AWS provides Direct Connect but it does not provide encryption level security on data movement through it by default. It's the customer's responsibility.
Comment: B: Creating an RDS instance and configuring the maintenance window is done by the customer. C: Adding monitoring, logging, etc on ECS is managed by the customer. F: Encrypting Direct Connect traffic is handled by the customer.
Comment: In question has 3 keyword "Amazon ECS", "AWS Direct Connect", "Amazon RDS". With per Amazon services, choose 1 according answer. Has 6 items, need pick 3 items. ECS --> choose C. Direct Connect --> choose F. RDS --> Excluse A (by keyword "infrastructure layer"), Choose B. Exclusive D (by keyword "patches for all minor and major database versions for Amazon RDS"). Exclusive E (by keyword "Ensure the physical security of the Amazon RDS"). Easy question.
Comment: BC & F ( no automatic encryption with direct connect
Comment: Amazon ECS is a fully managed service, the ops team only focus on building their applications, not the environment. Only option B and F makes sense.
Comment: Plus C (we were asked for three). Configuration (!) of components for monitoring, log management etc.; those services exist from AWS but you need to configure them (which logs do you want to store for how long etc.).
Comment: 100% BCF.
Comment: BCF B: Mentioned RDS C: Mentioned ECS F: Mentioned Direct connect
Comment: Yes BCF
Comment: I agree BCF
Comment: Bcf for me
Comment: THIS WAS IN MY EXAM
Comment: Never done it myself but apparently you can run Java in Lambda all the way to latest version https://docs.aws.amazon.com/lambda/latest/dg/lambda-java.html
Comment: can someone explain what makes A wrong, im aware that C hasnt covered all the requirements but A seems good with fargate serverless and autoscaling functionalities, plus AWS app2container is for .NET and JAVA
Comment: Statement: A company runs a Java-based job on an Amazon EC2 instance Requirement: The company wants to optimize the costs to run the job Regarding option A: App2Container is more likely for migratiing legacy application to conatiner based application. Which is not the main purpose of this use case. We are asked to reduce cost on a application that is already running under EC2 instance. So option B has the hight weight, cause lambda could perfectly do the job with the minimal cost
Comment: This question is intended for Lambda. Just searched for Lambda with Event bridge. I
Comment: Lambda allows you to allocate memory for your functions in increments of 1 MB, ranging from a minimum of 128 MB to a maximum of 10,240 MB (10 GB).
Comment: Remember - AWS Lambda function can go up to 10 GB of memory, instead of free tier only allow 512MB.
Comment: "AWS Batch jobs as EventBridge targets" at https://docs.aws.amazon.com/batch/latest/userguide/batch-cwe-target.html AWS Batch + Amazon EventBridge https://docs.aws.amazon.com/batch/latest/userguide/batch-cwe-target.html . AWS Lambda just for a point of time per period. Choose B.
Comment: 10 seconds to run, optimize the costs, consumes 1 GB of memory = AWS Lambda function.
Comment: AWS Lambda automatically scales resources to handle the workload, so you don't have to worry about managing the underlying infrastructure. It provisions the necessary compute resources based on the configured memory size (1 GB in this case) and executes the job in a serverless environment. By using Amazon EventBridge, you can create a scheduled rule to trigger the Lambda function every hour, ensuring that the job runs on the desired interval.
Comment: B - Within 10 sec and 1 GB Memory (Lambda Memory 128MB to 10GB)
Comment: https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html
Comment: Agreed, B Lambda
Comment: D, Governance is like the goverment, they can do things you cannot , like delete files or backups :D Compliance, nobody can!
Comment: Finally I understood!
Comment: Great analogy
Comment: D. Use AWS Backup to create a backup vault that has a vault lock in compliance mode. Create the required backup plan
Comment: D. Use AWS Backup to create a backup vault that has a vault lock in compliance mode. Create the required backup plan
Comment: Use AWS Backup to create a backup vault that has a vault lock in compliance mode. Create the required backup plan
Comment: Compliance mode
Comment: Must not alter the files for the duration of the retention period = Compliance Mode
Comment: D for sure.
Comment: https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
Comment: compliance mode
Comment: D bcs in governance we can delete backup
Comment: workload discovery=architecture diagram
Comment: https://docs.aws.amazon.com/solutions/latest/workload-discovery-on-aws/solution-overview.htmlWorkload Discovery on AWS is a visualization tool that automatically generates architecture diagrams of your workload on AWS. You can use this solution to build, customize, and share detailed workload visualizations based on live data from AWS
Comment: A: Systems Manager Inventory -> Metadata B: Not possible (correct me if I'm wrong) D: X-Ray is for application debugging C: Workload Discovery is purpose built tool for this type of usage
Comment: Even if B is possible, it has "manually" in it which we won't do because we're lazy in this question
Comment: Workload Discovery on AWS (formerly called AWS Perspective) is a tool to visualize AWS Cloud workloads. Use Workload Discovery on AWS to build, customize, and share detailed architecture diagrams of your workloads based on live data from AWS.
Comment: use Workload Discovery on AWS
Comment: Workload Discovery is purpose-built to automatically generate visual mappings of architectures across accounts and Regions. This makes it the most operationally efficient way to meet the requirements.
Comment: Option A: AWS SSM offers "Software inventory": Collect software catalog and configuration for your instances. Option C: Workload Discovery on AWS: is a tool for maintaining an inventory of the AWS resources across your accounts and various Regions and mapping relationships between them, and displaying them in a web UI.
Comment: https://aws.amazon.com/blogs/mt/visualizing-resources-with-workload-discovery-on-aws/
Comment: That is C
Comment: AWS Workload Discovery - create diagram, map and visualise AWS resources across AWS accounts and Regions
Comment: Workload Discovery on AWS can map AWS resources across AWS accounts and Regions and visualize them in a UI provided on the website.
Comment: https://aws.amazon.com/jp/builders-flash/202209/workload-discovery-on-aws/?awsf.filter-name=*all
Comment: Only C makes sense
Comment: Workload Discovery on AWS is a service that helps visualize and understand the architecture of your workloads across multiple AWS accounts and Regions. It automatically discovers and maps the relationships between resources, providing an accurate representation of the architecture.
Comment: Not sure here tbh To efficiently build and map the relationship details of various workloads across multiple AWS Regions and accounts, you can use the AWS Systems Manager Inventory feature in combination with AWS Resource Groups. Here's a solution that can help you achieve this: AWS Systems Manager Inventory:
Comment: only c mapping relationships
Comment: I don't see why adf has the most voted when almost everyone has chosen bdf, smh https://acloudguru.com/videos/acg-fundamentals/how-to-set-up-an-aws-billing-and-budget-alert?utm_source=google&utm_medium=paid-search&utm_campaign=cloud-transformation&utm_term=ssi-global-acg-core-dsa&utm_content=free-trial&gclid=Cj0KCQjwmtGjBhDhARIsAEqfDEcDfXdLul2NxgSMxKracIITZimWOtDBRpsJPpx8lS9T4NndKhbUqPIaAlzhEALw_wcB
Comment: IN MY EXAM
Comment: Its 11/Nov/2023. Options D&F are definitely required. As for the budget, right from the aws console, the only place to set this up is: AWS Billing>Cost Management>Budgets.
Comment: How to create a budget: Billing console > budget > create budget!
Comment: ACF: Option B is incorrect because the budget amount should be set under the Cost and Usage Reports section, not the Billing dashboards.
Comment: "Create an AWS Budget: Go to the AWS Billing Dashboard" https://awslabs.github.io/scale-out-computing-on-aws/workshops/TKO-Scale-Out-Computing/modules/071-budgets/
Comment: How to create a budget: Billing console > budget > create budget!
Comment: It is BDF because there is actually a Billing Dashboard available.
Comment: https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/view-billing-dashboard.html
Comment: BDF - Budgets can be set from the billing dashboard in AWS console
Comment: Currently, AWS does not have a specific feature called "AWS Billing Dashboards."
Comment: https://awslabs.github.io/scale-out-computing-on-aws/workshops/TKO-Scale-Out-Computing/modules/071-budgets/
Comment: if im not wrong, those are correct
Comment: Using AWS Backup, you can create backup plans that automate the backup process for your EC2 instances. By configuring cross-Region backup, you can ensure that backups are replicated to the second Region, providing a disaster recovery capability. This solution is cost-effective as it leverages AWS Backup's built-in features and eliminates the need for manual snapshot management or deploying and managing additional EC2 instances in the second Region.
Comment: Option B (EBS snapshots with cross-Region copy) is the most cost-effective solution for backing up EC2 instances to a second Region while allowing for centralized management and easy recovery when needed.
Comment: The answer is c
Comment: How does AWS Backup address that "The company also wants to provision EC2 resources in the second Region"?
Comment: With AWS Backup you can 'back up the EC2 instances to a second Region' by implementing cross-Region backup & 'provision EC2 resources in the second Region' by restoring the backup using the AWS Backup console. https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-resource.html
Comment: How do A, B or D address that? They want to "provision EC2 resources", nobody says that this should be copies of the existing servers. And if it should be copies of the existing servers, wouldn't we need the same (not "a similar") number of servers? We have no idea how many applications on how many servers they have.
Comment: C is the most cost-effective solution that meets all the requirements. AWS Backup provides automated backups across Regions for EC2 instances. This handles the backup requirement. AWS Backup is more cost-effective for cross-Region EC2 backups than using EBS snapshots manually or DataSync.
Comment: Well Datasync is to transfer data from on-prem to AWS rather than AWS R1 to R2, and it is use for a one-time migration rather than repetitive data migration activities like backups hence its out(on so many levels)
Comment: AWS backup
Comment: CCCCC . Create a backup plan by using AWS Backup. Configure cross-Region backup to the second Region for the EC2 instances.
Comment: CCCCCCC
Comment: C, i would say same, always AWS Backup
Comment: Option C stands out stronger because AWS Transfer Family securely scales your recurring business-to-business file transfers to AWS Storage services using SFTP, FTPS, FTP, and AS2 protocols. And AWS Lambda can be used to authenticate users with the company's IdP.
Comment: Ans : C To authenticate your users, you can use your existing identity provider with AWS Transfer Family. You integrate your identity provider using an AWS Lambda function, which authenticates and authorizes your users for access to Amazon S3 or Amazon Elastic File System (Amazon EFS). https://docs.aws.amazon.com/transfer/latest/userguide/custom-identity-provider-users.html
Comment: aws transfer family for data transfer and lamda function for idp authentication
Comment: https://aws.amazon.com/about-aws/whats-new/2022/07/aws-transfer-family-support-applicability-statement-2-as2/
Comment: To authenticate your users, you can use your existing identity provider with AWS Transfer Family. You integrate your identity provider using an AWS Lambda function, which authenticates and authorizes your users for access to Amazon S3 or Amazon Elastic File System (Amazon EFS).
Comment: Applicability Statement 2 (AS2) is a business-to-business (B2B) messaging protocol used to exchange Electronic Data Interchange (EDI) documents. With AWS Transfer Family's AS2 capabilities, you can securely exchange AS2 messages at scale while maintaining compliance and interoperability with your trading partners.
Comment: D is ok
Comment: its own IdP -> Lambda
Comment: https://docs.aws.amazon.com/transfer/latest/userguide/custom-identity-provider-users.html
Comment: C is correct. AWS Transfer Family supports the AS2 protocol, which is required by the company. Also, AWS Lambda can be used to authenticate users with the company's IdP, which meets the company's requirement.
Comment: Answer - D AS2 is a widely used protocol for secure and reliable data transfer. In this scenario, the company wants to transfer data using the AS2 protocol and authenticate application users using their own identity provider (IdP). AWS Storage Gateway provides a hybrid cloud storage solution that enables data transfer between on-premises environments and AWS. By using AWS Storage Gateway, you can set up a gateway that supports the AS2 protocol for data transfer. Additionally, you can configure authentication using an Amazon Cognito identity pool. Amazon Cognito provides a comprehensive authentication and user management service that integrates with various identity providers, including your own IdP. Therefore, Option D is the correct solution as it leverages AWS Storage Gateway for AS2 data transfer and allows authentication using an Amazon Cognito identity pool integrated with the company's IdP.
Comment: AWS Transfer Family also support AS2
Comment: https://repost.aws/articles/ARo2ihKKThT2Cue5j6yVUgsQ/articles/ARo2ihKKThT2Cue5j6yVUgsQ/aws-transfer-family-announces-support-for-sending-as2-messages-over-https?
Comment: C is correct
Comment: This is a new Qtn n AS2 is newly supported by AWS Transfer family.....good timing to know ur stuffs.
Comment: Option D looks the better option because it is more secure, scalable, cost-effective, and easy to use than option C.
Comment: AWS Storage Gateway supports the AS2 protocol for transferring data. By using AWS Storage Gateway, the company can integrate its own IdP authentication by creating an Amazon Cognito identity pool. Amazon Cognito provides user authentication and authorization capabilities, allowing the company to authenticate application users using its own IdP. AWS Transfer Family does not currently support the AS2 protocol. AS2 is a specific protocol used for secure and reliable data transfer, often used in business-to-business (B2B) scenarios. In this case, option C, which suggests using AWS Transfer Family, would not meet the requirement of using the AS2 protocol.
Comment: AWS Transfer Family now supports the Applicability Statement 2 (AS2) protocol, complementing existing protocol support for SFTP, FTPS, and FTP
Comment: This is not a case for storage gateway which is more used for a hybrid like environment. Here, to transfer data, we can think or Datasync or Transfer family and considering AS2 protocol, transfer family looks good
Comment: ChatGP To meet the requirements of using an identity provider (IdP) for user authentication and the AS2 protocol for data transfer, you can implement the following solution: AWS Transfer Family: Use AWS Transfer Family, specifically AWS Transfer for SFTP or FTPS, to handle the data transfer using the AS2 protocol. AWS Transfer for SFTP and FTPS provide fully managed, highly available SFTP and FTPS servers in the AWS Cloud. Not sure about Lamdba tho
Comment: Maybe yes The Lambda authorizer authenticates the token with the third-party identity provider.
Comment: Also from ChatGPT AWS Transfer Family supports multiple protocols, including AS2, and can be used for data transfer. By utilizing AWS Transfer Family, the company can integrate its own IdP authentication by creating an AWS Lambda function. Both options D and C are valid solutions for the given requirements. The choice between them would depend on additional factors such as specific preferences, existing infrastructure, and overall architectural considerations.
Comment: "The application will require that the data is in a relational format" so DynamoDB is out. RDS is the choice. Lambda is severless.
Comment: Why cant it be AC? We don't know the time of job runs right?
Comment: AWS Lambda and Amazon RDS
Comment: "2 GB of storage for its COMPUTATION resources" the maximum for Lambda is 512MB.
Comment: Lambda now supports upto 10GB of memory
Comment: I thought the same but seems like you can go all the way to 10gb. 512mb is the free tier https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-ephemeral-storage
Comment: At first I was thinking the same. But the computation memery for the lambda function is 1gb not 2gb. Hence. if you go to basic settings when you create the lambda function you can sellect a in the memori settings the 1024 MB (1Gb) and that solve the problem.
Comment: Relational Data RDS and computing for Lambda
Comment: bc for me
Comment: By activating a user-defined cost allocation tag named "department" and creating a cost report in Cost Explorer that groups by the tag name and filters by EC2, the accounting team will be able to track and attribute costs to specific departments across all AWS accounts within the organization. This approach allows for consistent cost allocation and reporting regardless of the AWS account structure.
Comment: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html
Comment: Management not user.
Comment: From the Organizations management account billing console, activate a user-defined cost allocation tag named department. Create one cost report in Cost Explorer grouping by tag name, and filter by EC2.
Comment: From the Organizations management account billing console, activate a user-defined cost allocation tag named department. Create one cost report in Cost Explorer grouping by tag name, and filter by EC2.
Comment: https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/activating-tags.html
Comment: a for me
Comment: Amazon AppFlow is a fully managed integration service that allows you to securely transfer data between different SaaS applications and AWS services. It provides built-in encryption options and supports encryption in transit using SSL/TLS protocols. With AppFlow, you can configure the data transfer flow from Salesforce to Amazon S3, ensuring data encryption at rest by utilizing AWS KMS CMKs.
Comment: ° Amazon AppFlow can securely transfer data between Salesforce and Amazon S3. ° AppFlow supports encrypting data at rest in S3 using KMS CMKs. ° AppFlow supports encrypting data in transit using HTTPS/TLS. ° AppFlow provides built-in support and templates for Salesforce and S3, requiring less custom configuration than solutions like Lambda, Step Functions, or custom connectors. ° So Amazon AppFlow is the easiest way to meet all the requirements of securely transferring data between Salesforce and S3 with encryption at rest and in transit.
Comment: i do like myself some appflow flow
Comment: SAAS=aws appflow
Comment: Ans : C Salesforce --------> Amazon AppFlow -----> S3
Comment: securely transfer data between Software-as-a-Service (SaaS) applications and AWS -> AppFlow
Comment: With Amazon AppFlow automate bi-directional data flows between SaaS applications and AWS services in just a few clicks
Comment: https://docs.aws.amazon.com/appflow/latest/userguide/what-is-appflow.html
Comment: All you need to know is that AWS AppFlow securely transfers data between different SaaS applications and AWS services
Comment: https://docs.aws.amazon.com/appflow/latest/userguide/salesforce.html
Comment: Saas with another service, AppFlow
Comment: Mobile gaming, UDP > AWS Global Accelarator + NLB
Comment: TCP/UDP/IP based communication with server =NLB for global low latency communication if IP/udp/tCP based = aws global accelarator
Comment: UDP == NLB NLB can't be used with Cloudfront, so we have to play with AWS Global accelerator
Comment: Use AWS Global Accelerator to create an accelerator. Create a Network Load Balancer (NLB) behind an accelerator endpoint that uses Global Accelerator integration and listening on the TCP and UDP ports. Update the Auto Scaling group to register instances on the NLB
Comment: TCP and UDP = global accelerator and Network Load Balancer
Comment: Clearly B.
Comment: NLB + Accelerator
Comment: AWS Global Accelerator+NLB
Comment: UDP, Global Accelerator plus NLB
Comment: AWS Global Accelerator is a better solution for the mobile gaming app than CloudFront
Comment: By decoupling the write operation from the processing operation using SQS, you ensure that the orders are reliably stored in the queue, regardless of the processing capacity of the EC2 instances. This allows the processing to be performed at a scalable rate based on the available EC2 instances, improving the overall reliability and speed of order processing.
Comment: IN MY EXAM
Comment: Decoupling the order processing from the application using Amazon SQS and leveraging Auto Scaling to handle the processing of orders based on the workload in the SQS queue is indeed the most efficient and scalable approach. This architecture addresses both reliability and performance concerns during traffic spikes.
Comment: Write orders to an Amazon Simple Queue Service (Amazon SQS) queue. Use EC2 instances in an Auto Scaling group behind an Application Load Balancer to read from the SQS queue and process orders into the database.
Comment: 100% B.
Comment: BBBBBBBBBB
Comment: AWS Lambda charges you based on the number of invocations and the execution time of your function. Since the data processing job is relatively small (2 MB of data), Lambda is a cost-effective choice. You only pay for the actual usage without the need to provision and maintain infrastructure.
Comment: but the question states "Data processing will require 1 GB of memory and will finish within 30 seconds." so it can't be C as Lambda support maximum 512M
Comment: C is valid. Lambda quotas: Memory - 128 MB to 10,240 MB, in 1-MB increments. Note: Lambda allocates CPU power in proportion to the amount of memory configured. You can increase or decrease the memory and CPU power allocated to your function using the Memory (MB) setting. At 1,769 MB, a function has the equivalent of one vCPU. Function timeout 900 seconds (15 minutes) 4 KB, for all environment variables associated with the function, in aggregate https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
Comment: Lambda can support upto 10 GB, But 512M is under free tier
Comment: I understand C is a common answer "throw Lambda" seems to be a common theme for questions that need processing under 15 minutes for the test. but in reality, can the other solutions be viable options as well?
Comment: That's the point here, technically all the options are good and will work, but since we are on a small amount of data Lambda will be the cheapest one, usually Glue or EMR will be kept for a big amount of data. Here is a topic where people did a comparison in comments : https://www.reddit.com/r/aws/comments/9umxv1/aws_glue_vs_lambda_costbenefit/
Comment: "processing will require 1 GB of memory and will finish within 30 seconds", perfect for AWS Lambda.
Comment: The data processing is lightweight, only requiring 1 GB memory and finishing in under 30 seconds. Lambda is designed for short, transient workloads like this. Lambda scales automatically, invoking the function as needed when new data arrives. No servers to manage. Lambda has a very low cost. You only pay for the compute time used to run the function, billed in 100ms increments. Much cheaper than provisioning EMR or Glue. Processing can begin as soon as new data hits the S3 bucket by triggering the Lambda function. Provides low latency.
Comment: I reckon C, but I would consider other well founded options.
Comment: c anyway the MOST cost-effectively
Comment: "minimize database downtime" so why create a new DB just modify the existing one so no time is wasted.
Comment: A is correct but reason need to be clarified: https://aws.amazon.com/blogs/database/best-practices-for-converting-a-single-az-amazon-rds-instance-to-a-multi-az-instance/ The instance doesn't automatically convert to Multi-AZ immediately. By default it will convert at next maintenance window but you can convert it immediately. Compared to B this is much better. CD are too many changes overall so unsuitable.
Comment: A. Convert the existing database instance to a Multi-AZ deployment by modifying the database instance and specifying the Multi-AZ option
Comment: Eliminate single points of failure = Multi-AZ deployment
Comment: A) https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html#Concepts.MultiAZ.Migrating
Comment: Compared to other solutions that involve creating new instances, restoring snapshots, or setting up replication manually, converting to a Multi-AZ deployment is a simpler and more streamlined approach with lower overhead. Overall, option A offers a cost-effective and efficient way to minimize database downtime without requiring significant changes or additional complexities.
Comment: A for HA, but also read replica can convert itself to master if the master is down... so not sure if C?
Comment: Sorry, the Route 53 doesnt make sense to sent requests to RR , what if is a write?
Comment: i guess aa
Comment: Multi-Attach is supported exclusively on Provisioned IOPS SSD (io1 and io2) volumes.
Comment:
hdd
Comment: AWS IO2 does support Multi-Attach. Multi-Attach allows you to share access to an EBS data volume between up to 16 Nitro-based EC2 instances within the same Availability Zone. Each attached instance has full read and write permission to the shared volume. This feature is intended to make it easier to achieve higher application availability for customers that want to deploy applications that manage storage consistency from multiple writers in shared storage infrastructure. However, please note that Multi-Attach on io2 is available in certain regions only.
Comment: C. Use Provisioned IOPS SSD (io2) EBS volumes with Amazon Elastic Block Store (Amazon EBS) Multi-Attach
Comment: Multi-Attach is supported exclusively on Provisioned IOPS SSD (io1 and io2) volumes. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html#:~:text=Multi%2DAttach%20is%20supported%20exclusively%20on%20Provisioned%20IOPS%20SSD%20(io1%20and%20io2)%20volumes.
Comment: Multi-Attach is supported exclusively on Provisioned IOPS SSD (io1 and io2) volumes. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html
Comment: The correct answer is A. Currently, Multi Attach EBS feature is supported by gp3 volumes also. Multi-Attach is supported for certain EBS volume types, including io1, io2, gp3, st1, and sc1 volumes.
Comment: No , Read this --> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html#considerations
Comment: Answer should be D
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html#considerations
Comment: By ChatGPT - Create General Purpose SSD (gp2) volumes: Provision multiple gp2 volumes with the required capacity for your application.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html#considerations
Comment: Multi-Attach does not support Provisioned IOPS SSD (io2) volumes. Multi-Attach is currently available only for General Purpose SSD (gp2), Throughput Optimized HDD (st1), and Cold HDD (sc1) EBS volumes.
Comment: Multi-Attach is supported exclusively on Provisioned IOPS SSD (io1 or io2) volumes.
Comment: only io1/io2 supports Multi-Attach
Comment: Multi-Attach is supported for certain EBS volume types, including io1, io2, gp3, st1, and sc1 volumes.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html#considerations
Comment: only io1/io2 supports Multi-Attach
Comment: Option D suggests using General Purpose SSD (gp2) EBS volumes with Amazon EBS Multi-Attach. While gp2 volumes support multi-attach, gp3 volumes offer a more cost-effective solution with enhanced performance characteristics.
Comment: I'm sorry : Multi-Attach enabled volumes can be attached to up to 16 instances built on the Nitro System that are in the same Availability Zone. Multi-Attach is supported exclusively on Provisioned IOPS SSD (io1 or io2) volumes.
Comment: The answer is C:
Comment: Answer - C C. Use Provisioned IOPS SSD (io2) EBS volumes with Amazon Elastic Block Store (Amazon EBS) Multi-Attach. While both option C and option D can support Amazon EBS Multi-Attach, using Provisioned IOPS SSD (io2) EBS volumes provides higher performance and lower latency compared to General Purpose SSD (gp2) volumes. This makes io2 volumes better suited for demanding and mission-critical applications where performance is crucial. If the goal is to achieve higher application availability and ensure optimal performance, using Provisioned IOPS SSD (io2) EBS volumes with Multi-Attach will provide the best results.
Comment: c is right Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances that are in the same Availability Zone. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html nothing about gp
Comment: Given that the scenario does not mention any specific requirements for high-performance or specific IOPS needs, using General Purpose SSD (gp2) EBS volumes with Amazon EBS Multi-Attach (option D) is typically the more cost-effective and suitable choice. General Purpose SSD (gp2) volumes provide a good balance of performance and cost, making them well-suited for general-purpose workloads.
Comment: gp2 - IOPS 16000 Nitro - IOPS 64000 - supported by io2. C is correct
Comment: I agree General Purpose SSD (gp2) volumes are the most common volume type. They were designed to be a cost-effective storage option for a wide variety of workloads. Gp2 volumes cover system volumes, dev and test environments, and various low-latency apps.
Comment: the question has not mentioned anything about cost-effective solution. only io1/io2 supports Multi-Attach plus fyi, gp3 is the one gives a good balance of performance and cost. so gp2 is wrong in every way
Comment: it's A
Comment: A. Configure the application to use Multi-AZ EC2 Auto Scaling and create an Application Load Balancer
Comment: Highly available = Multi-AZ EC2 Auto Scaling and Application Load Balancer.
Comment: Most likely A.
Comment: By combining Multi-AZ EC2 Auto Scaling and an Application Load Balancer, you achieve high availability for the EC2 instances hosting your stateless two-tier application.
Comment: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html Sign in to the AWS Management Console and open the AWS Billing console at https://console.aws.amazon.com/billing/ . Note Ensure you're logged in to the management account of your AWS Organizations.
Comment: So what exactly is the question?
Comment: It's an English test on complete the sentence...
Comment: What to do
Comment: I dont think there is a way for us to sell excess Savings plan. Only Selling Reserved instances is possible in marketplace
Comment: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html#ri-turn-on-process
Comment: I'd go with D, due to "The company uses less than 50% of its purchased compute power". Like, why are you sharing it between other accounts of the company, if the company itself doesn't need it? If you provisioned too much you can sell the overprovisioned capacity on the market. I'd understand B if it was about the account using about 50% of the plan and other accounts running similar workloads, but no such thing is stated.
Comment: Option E, Take it out of the salary of the guy who made the decision to purchase an entire compute plan without studying the company's needs.
Comment: in the question, it does not clarify then number of accounts the company has, if they only has one account, I think it is D,
Comment: what are you guys doing this section is for discussion not for copy paste
Comment: B, it's a generic Compute Savings Plan that can be used for compute workloads in the other accounts. A doesn't work, discount sharing must be enabled for all accounts (at least for those that provide and share the discounts). C is not possible, there's a reason why the workloads are in different accounts. D would be a last resort if there wouldn't be any other workloads in the own organization, but here are.
Comment: I saw similar question in older exam one can sell on the market unused capacity
Comment: B. Turn on discount sharing from the Billing Preferences section of the account console in the company's Organizations management account
Comment: Bro, no need to copy paste the answer that is already written. Need an explanation, I see that you just copy pasting the potential answers without any explanation in each discussion.
Comment: "For example, you might want to sell Reserved Instances after moving instances to a new AWS Region, changing to a new instance type, ending projects before the term expiration, when your business needs change, or if you have unneeded capacity." https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-general.html
Comment: D would make sense if the company wouldn't have other accounts with workloads. Or if it would be EC2 Savings Plans that would not match the instance types in other accounts. But it's a generic Compute Savings Plan that surely can be used in another account. Thus B.
Comment: I am also confused between B and D as the last part of the question "The company uses less than 50% of its purchased compute power." could imply that the whole company (not just this member account) only uses 50% of the computer power. If they said the member account only uses 50% then it would be clear cut B.
Comment: answer is B. https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html#:~:text=choose%20Save.-,Turning%20on%20shared%20reserved%20instances%20and%20Savings%20Plans%20discounts,-You%20can%20use
Comment: The company uses less than 50% of its purchased compute power. For this reason i believe D is the best solution : https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-general.html
Comment: The company Organization's management account can turn on/off shared reserved instances.
Comment: To summarize, option C (Migrate additional compute workloads from another AWS account to the account that has the Compute Savings Plan) is a valid solution to address the underutilization of the Compute Savings Plan. However, it involves workload migration and may require careful planning and coordination. Consider the feasibility and impact of migrating workloads before implementing this solution.
Comment: Answer - C If a member account within AWS Organizations has purchased a Compute Savings Plan
Comment: Asnwer - C
Comment: REST API with Amazon API Gateway: REST APIs are the appropriate choice for providing the frontend of the microservices application. Amazon API Gateway allows you to design, deploy, and manage REST APIs at scale. Amazon ECS in a Private Subnet: Hosting the application in Amazon ECS in a private subnet ensures that the containers are securely deployed within the VPC and not directly exposed to the public internet. Private VPC Link: To enable the REST API in API Gateway to access the backend services hosted in Amazon ECS, you can create a private VPC link. This establishes a private network connection between the API Gateway and ECS containers, allowing secure communication without traversing the public internet.
Comment: Question itself says: "The company must use REST APIs", hence WebSocket APIs are not applicable and such options are eliminated straight away.
Comment: "VPC links enable you to create private integrations that connect your HTTP API routes to private resources in a VPC, such as Application Load Balancers or Amazon ECS container-based applications."
Comment: I think the connection should be from the application to the ECS in the private VPC, instead of from the API Gateway to the ECS in the private VPC. API Gateway only needs to connect to the application...
Comment: AC are wrong as they are not REST API D, you don't make SG for API Gateway to EC2, you have to make a VPC Link. More details at https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vpc-links.html
Comment: To allow the REST APIs to securely access the backend, a private VPC link should be created from API Gateway to the ECS containers. A private VPC link provides private connectivity between API Gateway and the VPC without using public IP addresses or requiring an internet gateway/NAT
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-private-integration.html
Comment: A VPC link is a resource in Amazon API Gateway that allows for connecting API routes to private resources inside a VPC.
Comment: B is the right choice
Comment: Why Not D
Comment: A security group acts as a firewall for associated EC2 instances, controlling both inbound and outbound traffic at the instance level.
Comment: b is right, bcs vpc link provided security connection
Comment: S3 Inventory can't to move files to another class
Comment: Unpredictable access pattern = Intelligent-Tiering.
Comment: C. Use S3 Lifecycle rules to transition objects from S3 Standard to S3 Intelligent-Tiering
Comment: Cannot predict access pattern = S3 Intelligent-Tiering.
Comment: Not known patterns, Intelligent Tier
Comment: For exam, egress-only internet gateway: IPv6 NAT gateway: IPv4
Comment: Good stuff. "An egress-only internet gateway is for use with IPv6 traffic only. To enable outbound-only internet communication over IPv4, use a NAT gateway instead." https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html
Comment: This is very helpful, thanks.
Comment: thanks a lot
Comment: An egress-only internet gateway (EIGW) is specifically designed for IPv6-only VPCs and provides outbound IPv6 internet access while blocking inbound IPv6 traffic. It satisfies the requirement of preventing external services from initiating connections to the EC2 instances while allowing the instances to initiate outbound communications.
Comment: Since the company's security policy explicitly states that external services cannot initiate connections to the EC2 instances, using a NAT gateway (option A) would not be suitable. A NAT gateway allows outbound connections from private subnets to the internet, but it does not restrict inbound connections from external sources.
Comment: "A NAT gateway ... does not restrict inbound connections from external sources." Actually it does, but only for IPv4.
Comment: Enable outbound IPv6 traffic using an egress-only internet gateway https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html
Comment: "An egress-only internet gateway is for use with IPv6 traffic only. To enable outbound-only internet communication over IPv4, use a NAT gateway instead." https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html
Comment: D. Create an egress-only internet gateway and make it the destination of the subnet's route table
Comment: Outbound traffic only = Create an egress-only internet gateway and make it the destination of the subnet's route table
Comment: Egress-Only internet Gateway
Comment: Amazon S3 supports both gateway endpoints and interface endpoints. With a gateway endpoint, you can access Amazon S3 from your VPC, without requiring an internet gateway or NAT device for your VPC, and with no additional cost. However, gateway endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a transit gateway. For those scenarios, you must use an interface endpoint, which is available for an additional cost.
Comment: Gateway VPC Endpoint: A gateway VPC endpoint enables private connectivity between a VPC and Amazon S3. It allows direct access to Amazon S3 without the need for internet gateways, NAT devices, VPN connections, or AWS Direct Connect. Minimize Internet Traffic: By creating a gateway VPC endpoint for Amazon S3 and associating it with all route tables in the VPC, the traffic between the VPC and Amazon S3 will be kept within the AWS network. This helps in minimizing data transfer costs and prevents the need for traffic to traverse the internet. Cost-Effective: With a gateway VPC endpoint, the data transfer between the application running in the VPC and the S3 bucket stays within the AWS network, reducing the need for data transfer across the internet. This can result in cost savings, especially when dealing with large amounts of data.
Comment: Option B (Enable S3 Transfer Acceleration for the S3 bucket) is a feature that uses the CloudFront global network to accelerate data transfers to and from Amazon S3. While it can improve data transfer speed, it still involves traffic traversing the internet and doesn't directly address the goal of minimizing costs and preventing internet traffic whenever possible.
Comment: https://aws.amazon.com/blogs/architecture/choosing-your-vpc-endpoint-strategy-for-amazon-s3/ A: Storage cost is not described as an issue here B: Tx Accelerator is for external (global user) traffic acceleration D: Interface endpoint is on-prem to S3 C: gateway VPC is specifically for S3 to AWS resources
Comment: Interface endpoints are not exclusively for on-prem to S3. The only reason why option D is wrong is because "Associate this endpoint with all route tables in the VPC" makes no sense.
Comment: I think both C&D will works. But D will have extra cost. So C is correct.
Comment: C. Create a gateway VPC endpoint for Amazon S3. Associate this endpoint with all route tables in the VPC
Comment: Prevent traffic from traversing the internet = Gateway VPC endpoint for S3.
Comment: Key word transversing to internet
Comment: Gateway endpoint for S3
Comment: vpc endpoint for s3
Comment: B and C do not reduce latency. D would reduce latency but require significant application changes.
Comment: D would not reduce latency, all the messages are new, they wont be stored in cache and they are unique messages(dynamic content) so Elasticache would be pointless here, its more preferable for static content/frequently accessed content.... A makes perfect sense
Comment: 0 code change @C ABD. In memory cache, read replica, elasticache. Chat application and content is dynamic, cache will still pull data from prod database
Comment: C has 0 codes changes but doesn't address the issue.
Comment: Would go for A. Minimal application changes != No application changes
Comment: "requires minimal application changes" - Do not choose A because it requires updates of codes.
Comment: C is correct A, B and D all require code changes to the app.
Comment: A. Configure Amazon DynamoDB Accelerator (DAX) for the new messages table. Update the code to use the DAX endpoint.
Comment: Read replica does improve the read speed, but it cannot improve the latency because there is always latency between replicas. So A works and B not work.
Comment: C , "requires minimal application changes"
Comment: little latency = Amazon DynamoDB Accelerator (DAX) .
Comment: I go with A https://aws.amazon.com/blogs/mobile/building-a-full-stack-chat-application-with-aws-and-nextjs/ but I have some doubts about this https://aws.amazon.com/blogs/database/how-to-build-a-chat-application-with-amazon-elasticache-for-redis/
Comment: Amazon DynamoDB Accelerator (DAX): DAX is an in-memory cache for DynamoDB that provides low-latency access to frequently accessed data. By configuring DAX for the new messages table, read requests for the table will be served from the DAX cache, significantly reducing the latency. Minimal Application Changes: With DAX, the application code can be updated to use the DAX endpoint instead of the standard DynamoDB endpoint. This change is relatively minimal and does not require extensive modifications to the application's data access logic. Low Latency: DAX caches frequently accessed data in memory, allowing subsequent read requests for the same data to be served with minimal latency. This ensures that new messages can be read by users with minimal delay.
Comment: Option B (Add DynamoDB read replicas) involves creating read replicas to handle the increased read load, but it may not directly address the requirement of minimizing latency for new message reads.
Comment: Tricky one, in doubt also with B, read replicas.
Comment: Yes it's tricky but least code changes is the tie breaker. DAX has zero code changes.
Comment: a is valid
Comment: The problem with this question is that no sane AWS architect will chose any of these options and go for S3 caching. But given the choices, A is the only one which will solve the problem within reasonable cost.
Comment: A. Create an Amazon CloudFront distribution to cache state files at edge locations
Comment: Serves static content = Amazon CloudFront distribution.
Comment: Amazon CloudFront: CloudFront is a content delivery network (CDN) service that caches content at edge locations worldwide. By creating a CloudFront distribution, static content from the website can be cached at edge locations, reducing the load on the EC2 instances and improving the overall performance. Caching Static Files: Since the website serves static content, caching these files at CloudFront edge locations can significantly reduce the number of requests forwarded to the EC2 instances. This helps to lower the overall cost by offloading traffic from the instances and reducing the data transfer costs.
Comment: a for me
Comment: The correct answer is: C. Use AWS Transit Gateway to manage VPC communication in a single Region and Transit Gateway peering across Regions to manage VPC communications. AWS Transit Gateway is a network hub that you can use to connect your VPCs and on-premises networks. It provides a single point of control for managing your network traffic, and it can help you to reduce the number of connections that you need to manage. Transit Gateway peering allows you to connect two Transit Gateways in different Regions. This can help you to create a global network that spans multiple Regions. To use Transit Gateway to manage VPC communication in a single Region, you would create a Transit Gateway in each Region. You would then attach your VPCs to the Transit Gateway. To use Transit Gateway peering to manage VPC communication across Regions, you would create a Transit Gateway peering connection between the Transit Gateways in each Region.
Comment: thank you for this comprehensive explanation
Comment: AWS Transit Gateway: Transit Gateway is a highly scalable service that simplifies network connectivity between VPCs and on-premises networks. By using a Transit Gateway in a single Region, you can centralize VPC communication management and reduce administrative effort. Transit Gateway Peering: Transit Gateway supports peering connections across AWS Regions, allowing you to establish connectivity between VPCs in different Regions without the need for complex VPC peering configurations. This simplifies the management of VPC communications across Regions.
Comment: C is like a managed solution for A. A can work but with a lot of overhead (CIDR blocks uniqueness requirement). B and D are not the right products
Comment: multiple regions + multiple VPCs --> Transit Gateway
Comment: Definitely C. Very well explained by @Felix_br
Comment: Ccccccccccccccccccccc if you have services in multiple Regions, a Transit Gateway will allow you to access those services with a simpler network configuration.
Comment: https://aws.amazon.com/efs/faq/ Q: What is Amazon EFS Replication? EFS Replication can replicate your file system data to another Region or within the same Region without requiring additional infrastructure or a custom process. Amazon EFS Replication automatically and transparently replicates your data to a second file system in a Region or AZ of your choice. You can use the Amazon EFS console, AWS CLI, and APIs to activate replication on an existing file system. EFS Replication is continual and provides a recovery point objective (RPO) and a recovery time objective (RTO) of minutes, helping you meet your compliance and business continuity goals.
Comment: The key thing to notice here in the question is "with a recovery point objective (RPO) of 8 hours", as it is 8 hours of time it recovery can be easily managed by EFS, no need to go for costlier and not built for this use-case(share file system) options like NetApp ONTAP(proprietary data cluster), OpenZFS(not a built in filesystem in AWS) or FSx for windows(file system for windows compatible workloads)
Comment: A: ECS is not Windows File Server so won't work B: ONTAP is proprietary data cluster completely unrelated to this question D: OpenZFS needs a Linux kind of host for access. Not a built-in filesystem in AWS by default
Comment: "The file systemhttps://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/view/48/# needs to provide a mount target in each (!) Availability Zone within a Region", most regions have three AZs, but FSx Multi-AZ provides only nodes "spread across two AZs". While "or Amazon EFS file systems that use Regional storage classes [such as Standard], you can create a mount target in each Availability Zone in an AWS Region."
Comment: Huh, comment has been scrambled a bit. Anyway FSx Multi-AZ: Mount targets in two AZs EFS Standard: Can create mount target in each AZ
Comment: In the absence of this information, we can only make an assumption based on the provided requirements. The requirement for a shared file system that can recover data to another AWS Region with a recovery point objective (RPO) of 8 hours, and the need for a mount target in each Availability Zone within a Region, are all natively supported by Amazon EFS with the Standard storage class. While Amazon FSx for NetApp ONTAP does provide shared file systems and supports both Windows and Linux, it does not natively support replication to another region through AWS Backup.
Comment: C. Amazon Elastic File System (Amazon EFS) with the Standard storage class
Comment: B or C, but since question didn't mention operating system type, I guess we should go with B because it is more versatile (EFS supports Linux only), although ECS containers do support windows instances...
Comment: Both option B and C will support this requirement. https://aws.amazon.com/efs/faq/#:~:text=What%20is%20Amazon%20EFS%20Replication%3F https://aws.amazon.com/fsx/netapp-ontap/faqs/#:~:text=How%20do%20I%20configure%20cross%2Dregion%20replication%20for%20the%20data%20in%20my%20file%20system%3F
Comment: BBBBBBBBBBBBBBB
Comment: Both B and C are feasible. Amazon FSx for NetApp ONTAP is just way overpriced for a backup storage solution. The keyword to look out for is sub milli seconds latency In real life env, Amazon Elastic File System (Amazon EFS) with the Standard storage class is good enough.
Comment: Efs, can be mounted only in 1 region So the answer is B
Comment: C: EFS
Comment: Selected Answer: C AWS Backup can manage replication of EFS to another region as mentioned below https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html
Comment: https://aws.amazon.com/efs/faq/ During a disaster or fault within an AZ affecting all copies of your data, you might experience loss of data that has not been replicated using Amazon EFS Replication. EFS Replication is designed to meet a recovery point objective (RPO) and recovery time objective (RTO) of minutes. You can use AWS Backup to store additional copies of your file system data and restore them to a new file system in an AZ or Region of your choice. Amazon EFS file system backup data created and managed by AWS Backup is replicated to three AZs and is designed for 99.999999999% (11 nines) durability.
Comment: Amazon EFS is a scalable and durable elastic file system that can be used with Amazon ECS. However, it does not support replication to another AWS Region.
Comment: To use EFS replication in a Region that is disabled by default, you must first opt in to the Region, so it does support.
Comment: it does support replication to another AWS Region check the same link you are replying to :/ https://aws.amazon.com/efs/faq/ Q: What is Amazon EFS Replication? EFS Replication can replicate your file system data to another Region or within the same Region without requiring additional infrastructure or a custom process. Amazon EFS Replication automatically and transparently replicates your data to a second file system in a Region or AZ of your choice. You can use the Amazon EFS console, AWS CLI, and APIs to activate replication on an existing file system. EFS Replication is continual and provides a recovery point objective (RPO) and a recovery time objective (RTO) of minutes, helping you meet your compliance and business continuity goals.
Comment: shared file system that is highly durable and can recover data
Comment: Why not EFS?
Comment: Option B is incorrect because IAM roles are not directly attached to IAM groups.
Comment: IAM Roles can be attached to IAM Groups: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/assign_role.html
Comment: Read your own link: You can assign an existing IAM role to an AWS Directory Service user or group. Not to IAM groups.
Comment: Agreed with C https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html Attaching a policy to an IAM user group
Comment: "Manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources." "An IAM role is an identity within your AWS account that has specific permissions. It's similar to an IAM user, but isn't associated with a specific person." "IAM roles do not have any permanent credentials associated with them and are instead assumed by IAM users, AWS services, or applications that need temporary security credentials to access AWS resources"
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html https://blog.awsfundamentals.com/aws-iam-roles-terms-concepts-and-examples
Comment: create role=for resource like EC2 and lambda .... create a Policy =for groups or user access policy for the resources like S3 bucket
Comment: Not A or D because this is not about restricting maximum permissions, it is is about securely granting permissions Not B because IAM roles are not attached to IAM groups. C because IAM policies are attached to IAM groups.
Comment: A is wrong SCPs are mainly used along with AWS Organizations organizational units (OUs). SCPs do not replace IAM Policies such that they do not provide actual permissions. To perform an action, you would still need to grant appropriate IAM Policy permissions.
Comment: Create an IAM policy that grants least privilege permission. Attach the policy to the IAM groups
Comment: An IAM policy is an object in AWS that, when associated with an identity or resource, defines their permissions. Permissions in the policies determine whether a request is allowed or denied. You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. So, option B will also work. But Since I can only choose one, C would be it.
Comment: You can attach up to 10 IAM policy for a 'user group'.
Comment: C is the correct one.
Comment: should be b
Comment: it should be C
Comment: Option C is not as secure as option B because IAM policies are attached to individual users and cannot be used to manage permissions for groups of users.
Comment: IAM Roles manage who has access to your AWS resources, whereas IAM policies control their permissions. A Role with no Policy attached to it won't have to access any AWS resources. A Policy that is not attached to an IAM role is effectively unused.
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
Comment: IAM roles are not attached to IAM groups. IAM policies are attached to IAM roles, IAM groups or IAM users. IAM roles are used by services.
Comment: option B action is S3:*. this means all actions. The company follows least-privilege access rules. Hence option D
Comment: D is the answer
Comment: what's the difference between B and D? on B the statements are just placed in another order
Comment: option B action is S3:*. this means all actions. The company follows least-privilege access rules. Hence option D
Comment: What is the difference between C and D?
Comment: the "/" at the end of the last line on D
Comment: so annoying when you oversee this"/"
Comment: D for sure
Comment: d work
Comment: Agreed
Comment: Option A allows the files to be modified or deleted by anyone with read-only IAM permissions. Option C allows the files to be modified or deleted by anyone who can trigger the AWS Lambda function. Option D allows the files to be modified or deleted by anyone with read-only IAM permissions to the S3 bucket
Comment: no it doesnt, did you not notice this part: "S3 Object Lock with a retention period in accordance with the designated date", this part avoids deletion/modification of files
Comment: Versioning Enabled + Object Lock = B
Comment: Object Lock works only in buckets that have S3 Versioning enabled. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Comment: S3 bucket policy
Comment: B is correct. A doesnot have S3 object lock, but deletion is prohibited, which implies object lock C does not have S3 as static web, but have to share the s3 with the public D mentions files - but S3 manages objects, not file
Comment: D? Its like B, but also with read-only access limitations for anyone with IAM permissions. Also versioning in B doesn't help with anything.
Comment: Enabling versioning is a pre-requisite for object lock.
Comment: Create a new Amazon S3 bucket with S3 Versioning enabled. Use S3 Object Lock with a retention period in accordance with the designated date. Configure the S3 bucket for static website hosting. Set an S3 bucket policy to allow read-only access to the objects.
Comment: Create a new Amazon S3 bucket with S3 Versioning enabled. Use S3 Object Lock with a retention period in accordance with the designated date. Configure the S3 bucket for static website hosting. Set an S3 bucket policy to allow read-only access to the objects.
Comment: Clearly B.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Comment: Just Think Infrastructure as Code=== Cloud Formation
Comment: The difference between CloudFormation and Beanstalk might be trick, but just for the exam think: Cloudformation -> Infra as Code Beanstalk -> deploy and manage applications
Comment: A: Wrong product C: Wrong product D: EBS can only handle EC2 so RDS won't be replicated automatically B: CloudFormation = IaaC
Comment: Just Think Infrastructure as Code=== Cloud Formation
Comment: Why D is not correct?
Comment: I guess it's because Beanstalk is PaaS (platform as a service) while CloudFormation is IaC (infrastructure as code). The question emphasis more on infrastructure
Comment: I guess "TEMPLATE" leads to CloudFormation
Comment: Infrastructure as code = AWS CloudFormation
Comment: Clearly B.
Comment: AWS CloudFormation is a service that allows you to define and provision infrastructure as code. This means that you can create a template that describes the resources you want to create, and then use CloudFormation to deploy those resources in an automated fashion. In this case, the solutions architect should define the infrastructure as a template by using the prototype infrastructure as a guide. The template should include resources for an Auto Scaling group, an Application Load Balancer, and an Amazon RDS database. Once the template is created, the solutions architect can use CloudFormation to deploy the infrastructure in two Availability Zones.
Comment: B Define the infrastructure as a template by using the prototype infrastructure as a guide. Deploy the infrastructure with AWS CloudFormation
Comment: b obvious
Comment: A VPC endpoint enables you to privately access AWS services without requiring internet gateways, NAT gateways, VPN connections, or AWS Direct Connect connections. It allows you to connect your VPC directly to supported AWS services, such as Amazon S3, over a private connection within the AWS network. By creating a VPC endpoint for Amazon S3, the traffic between your EC2 instances and S3 will stay within the AWS network and won't traverse the public internet. This provides a more secure and compliant solution, as the data transfer remains within the private network boundaries.
Comment: Prevent traffic from traversing the internet = VPC endpoint for S3.
Comment: B until proven contrary.
Comment: B for sure
Comment: BBBBBBBBB
Comment: In the write-through caching strategy, when a customer adds or updates an item in the database, the application first writes the data to the database and then updates the cache with the same data. This ensures that the cache is always synchronized with the database, as every write operation triggers an update to the cache.
Comment: Lazy loading caching strategy (option A) typically involves populating the cache only when data is requested, and it does not guarantee that the data in the cache always matches the data in the database. Adding TTL (Time-to-Live) caching strategy (option C) involves setting an expiration time for cached data. It is useful for scenarios where the data can be considered valid for a specific period, but it does not guarantee that the data in the cache is always in sync with the database. AWS AppConfig caching strategy (option D) is a service that helps you deploy and manage application configurations. It is not specifically designed for caching data synchronization between a database and cache layer.
Comment: Great explanation , thanks
Comment: write-through cashing strategy
Comment: In exam
Comment: More helpful reading for why B is the answer: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html#Strategies.WriteThrough
Comment: B. Implement the write-through caching strategy
Comment: The answer is definitely B. I couldn't provide any more details than what has been shared by @cloudenthusiast.
Comment: write-through caching strategy updates the cache at the same time as the database
Comment: AWS DataSync is a fully managed data transfer service that simplifies and automates the process of moving data between on-premises storage and Amazon S3. It provides secure and efficient data transfer with built-in encryption, ensuring that the data is encrypted in transit. By using AWS DataSync, the company can easily migrate the 100 GB of historical data from their on-premises location to an S3 bucket. DataSync will handle the encryption of data in transit and ensure secure transfer.
Comment: Using DataSync, the company can easily migrate the 100 GB of historical data to an S3 bucket. DataSync will handle the encryption of data in transit, so the company does not need to set up a VPN or worry about managing encryption keys. Option A, using the s3 sync command in the AWS CLI to move the data directly to an S3 bucket, would require more operational overhead as the company would need to manage the encryption of data in transit themselves. Option D, setting up an IPsec VPN from the on-premises location to AWS, would also require more operational overhead and would be overkill for this scenario. Option C, using AWS Snowball, could work but would require more time and resources to order and set up the physical device.
Comment: Why would u u se the CLI
Comment: Assertions: - needs to encrypt the data in transit to the S3 bucket. - The company will store new data directly in Amazon S3. Requirements: - with the LEAST operational overhead Even Though options A and B could do the job, option A requires VM maintenance because it is not a once-off migration (The company will store new data directly in Amazon S3) NB: According to me, we must stuck to the question and avoid to interpret
Comment: Erratum: Assertions: - needs to encrypt the data in transit to the S3 bucket. - The company will store new data directly in Amazon S3. Requirements: - with the LEAST operational overhead Even Though options A and B could do the job, option B requires VM maintenance because it is not a once-off migration (The company will store new data directly in Amazon S3) NB: According to me, we must stuck to the question and avoid to interpret
Comment: A - one single command, uses encryption automatically B - Must install, configure and eventually decommission DataSync C - Overkill D - No need for VPN
Comment: I agree, A is a million times simpler than B in terms of operational setup. AWS CLI is just one install on a server on client side and one command (literally) to sync the data.
Comment: By default, all data transmitted from the client computer running the AWS CLI and AWS service endpoints is encrypted by sending everything through a HTTPS/TLS connection. You don't need to do anything to enable the use of HTTPS/TLS. It is always enabled unless you explicitly disable it for an individual command by using the --no-verify-ssl command line option. This is simpler compared to datasync, which will cost operational overhead to configure.
Comment: storage data (including metadata) is encrypted in transit, but how it's encrypted throughout the transfer depends on your source and destination locations.
Comment: B is correct to migrate A is incorrect because is it only used to upload minor files (about a few GB) to AWS. 100 GB is not appropriate.
Comment: There is no limitation on AWS CLI s3 sync command transfer size. Not that I can find in the docs. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/sync.html Happy to be corrected!
Comment: Use AWS DataSync to migrate the data from the on-premises location to an S3 bucket
Comment: B is a good option but as the volume is not large and the speed is not bad, A requires less operational overhead
Comment: Answer A and B both are correct and with least operational overhead. But since the question says from an "On-premise Location" hence I would go with DataSync.
Comment: AWS DataSync is a secure, online service that automates and accelerates moving data between on premises and AWS Storage services.
Comment: Why not A? s3 is already encrypted in transit by TLS. We need to have the LEAST operational overhead and DataSync implies the installation of Agent whereas AWS CLI is easier to use.
Comment: I can think of two reasons. - S3 does have HTTP and HTTPS endpoints available. - DataSync offers data compression - considering the question mentions of internet bandwidth is mentioned.
Comment: https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html
Comment: Answer - A Use the s3 sync command in the AWS CLI to move the data directly to an S3 bucket.
Comment: Lambda supports only Linux-based container images. https://docs.aws.amazon.com/lambda/latest/dg/images-create.html
Comment: Not really. Lambda supports .Net 6 directly: https://aws.amazon.com/blogs/compute/introducing-the-net-6-runtime-for-aws-lambda/
Comment: By using Amazon ECS on AWS Fargate, you can run the job in a containerized environment while benefiting from the serverless nature of Fargate, where you only pay for the resources used during the job's execution. Creating a scheduled task based on the container image of the job ensures that it runs every 10 minutes, meeting the required schedule. This solution provides flexibility, scalability, and cost-effectiveness.
Comment: A A A A A A
Comment: selected answer : A AWS Lambda now supports .NET 6 as both a managed runtime and a container base image
Comment: https://aws.amazon.com/about-aws/whats-new/2022/02/aws-lambda-adds-support-net6/
Comment: The question is weirdly phrased for .Net based containers. "A company containerized a Windows job that runs on .NET 6 Framework under a Windows container." This could mean that the job requires .Net 6 Framework OR it could mean the job requires Windows and .Net Framework 6. If the job is just based on .Net 6 then Lambda can run it. I am just a bit cautious about language because other parameters fall under Lambda. Question may have been wrongly quoted here.
Comment: I guess this is an old question from before August 2023, when AWS Batch did not support Windows containers, while ECS already did since September 2021. Thus it would be C, though now B does also work. Since both Batch and ECS are free, we'd pay only for the Fargate resources (which are identical in both cases), now B and C would be correct. A doesn't work because Lambda still does not support Windows containeres. D doesn't make sense because the container would have to run 24/7
Comment: I think that Batch with Fargate is more cheaper than ECS.
Comment: Both Batch and ECS are free. https://aws.amazon.com/de/ecs/pricing/ https://aws.amazon.com/de/batch/pricing/
Comment: Batch supports fargate now
Comment: aws batch supports fargate
Comment: C works. For A, the lambda support container image, but the container image much implement the Lambda Runtime API.
Comment: Absolutely agree with this one ... Lambda do not support Windows container, on the other hand ECS is adequate solution
Comment: As they support Batch on Fargate now (Aug 2023), the correct answer should be B?
Comment: that's exactly my question too. In one of the discussions, they same lambda is for jobs for 15 min. But for other question, they same batch is the best. I do not understand why we cant use batch?
Comment: https://docs.aws.amazon.com/lambda/latest/dg/csharp-image.html#csharp-image-clients
Comment: But it's clearly "a Windows job". Lambda does not support Windows containers. (.NET 6 could also run under Linux, but they'd need to modify the container in any case.)
Comment: C is the most cost-effective solution for running a short-lived Windows container job on a schedule. Using Amazon ECS scheduled tasks on Fargate eliminates the need to provision EC2 resources. You pay only for the duration the task runs. Scheduled tasks handle scheduling the jobs and scaling resources automatically. This is lower cost than managing your own scaling via Lambda or Batch. ECS also supports Windows containers natively unlike Lambda (option A). Option D still requires provisioning and paying for full time EC2 resources to run a task scheduler even when tasks are not running.
Comment: August 2023, AWS Batch now support Windows container https://docs.aws.amazon.com/batch/latest/userguide/fargate.html#when-to-use-fargate
Comment: https://aws.amazon.com/blogs/containers/running-windows-containers-with-amazon-ecs-on-aws-fargate/
Comment: For those wonder why not B AWS Batch doesn't support Windows containers on either Fargate or EC2 resources. https://docs.aws.amazon.com/batch/latest/userguide/fargate.html#when-to-use-fargate:~:text=AWS%20Batch%20doesn%27t%20support%20Windows%20containers%20on%20either%20Fargate%20or%20EC2%20resources.
Comment: They have now added support, which now makes B true? https://aws.amazon.com/about-aws/whats-new/2023/07/aws-batch-fargate-linux-arm64-windows-x86-containers-cli-sdk/
Comment: the actual exam is not up-to-date, it came out in August 30, 2022
Comment: A: Lambda supports containerized applications
Comment: A. By creating a new organization in AWS Organizations, you can establish a consolidated multi-account architecture. This allows you to create and manage multiple AWS accounts for different business units under a single organization. E. Setting up AWS IAM Identity Center (AWS Single Sign-On) within the organization enables you to integrate it with the company's corporate directory service. This integration allows for centralized authentication, where users can sign in using their corporate credentials and access the AWS accounts within the organization. Together, these actions create a centralized, multi-account architecture that leverages AWS Organizations for account management and AWS IAM Identity Center (AWS Single Sign-On) for authentication and access control.
Comment: A) Using AWS Organizations allows centralized management of multiple AWS accounts in a single organization. New accounts can easily be created within the organization. E) Integrating AWS IAM Identity Center (AWS SSO) with the company's corporate directory enables federated single sign-on. Users can log in once to access accounts and resources across AWS. Together, Organizations and IAM Identity Center provide consolidated management and authentication for multiple accounts using existing corporate credentials.
Comment: A:AWS Organization E:Authentication because option C (SCP) for Authorization
Comment: Ans: CD ‘centralized corporate directory service' with new accounts in AWS Organizations
Comment: Create a new organization in AWS Organizations with all features turned on. Create the new AWS accounts in the organization. Set up AWS IAM Identity Center (AWS Single Sign-On) in the organization. Configure IAM Identity Center, and integrate it with the company's corporate directory service. AWS IAM Identity Center (successor to AWS Single Sign-On) helps you securely create or connect your workforce identities and manage their access centrally across AWS accounts and applications. https://aws.amazon.com/iam/identity-center/#:~:text=AWS%20IAM%20Identity%20Center%20(successor%20to%20AWS%20Single%20Sign%2DOn)%20helps%20you%20securely%20create%20or%20connect%20your%20workforce%20identities%20and%20manage%20their%20access%20centrally%20across%20AWS%20accounts%20and%20applications.
Comment: ae is right
Comment: By choosing Expedited retrievals in Amazon S3 Glacier, you can reduce the retrieval time to minutes, making it suitable for scenarios where quick access is required. Expedited retrievals come with a higher cost per retrieval compared to standard retrievals but provide faster access to your archived data.
Comment: The most cost-effective solution that also meets the requirement of having the files available within a maximum of five minutes when needed is: A. Store the video archives in Amazon S3 Glacier and use Expedited retrievals. Amazon S3 Glacier is designed for long-term storage of data archives, providing a highly durable and secure solution at a low cost. With Expedited retrievals, data can be retrieved within a few minutes, which meets the requirement of having the files available within five minutes when needed. This option provides the balance between cost-effectiveness and retrieval speed, making it the best choice for the company's needs.
Comment: Occasional cost for retrieval from Glacier is nothing compared to the huge storage cost savings compared to C. Still meets the five minute requirement.
Comment: The retrieval price will play an important role here. I selected the "C" option because in "Glacier and use Expedited retrievals" its around $0.004 per GB/month and for STD-IA $0.0125 per GB/month https://www.cloudforecast.io/blog/aws-s3-pricing-and-optimization-guide/
Comment: But they "will rarely need to restore their files", thus the low cost for occasional expedited retrievals will be nothing compared to the huge storage cost savings.
Comment: s3 expedited can only be applied on glacier flexible retrieval storage class and s3 intelligent tiering archive access tier. so the answer should be C
Comment: A mentions "G3 Glacier" which has been renamed to "S3 Glacier Flexible Retrieval" and meets the requirements.
Comment: I am going with option A, but it is a poorly written question. "For all but the largest archives (more than 250 MB), data accessed by using Expedited retrievals is typically made available within 1–5 minutes. "
Comment: Answer - A Fast availability: Although retrieval times for objects stored in Amazon S3 Glacier typically range from minutes to hours, you can use the Expedited retrievals option to expedite access to your archives. By using Expedited retrievals, the files can be made available in a maximum of five minutes when needed. However, Expedited retrievals do incur higher costs compared to standard retrievals.
Comment: Expedited retrievals are designed for urgent requests and can provide access to data in as little as 1-5 minutes for most archive objects. Standard retrievals typically finish within 3-5 hours for objects stored in the S3 Glacier Flexible Retrieval storage class or S3 Intelligent-Tiering Archive Access tier. These retrievals typically finish within 12 hours for objects stored in the S3 Glacier Deep Archive storage class or S3 Intelligent-Tiering Deep Archive Access tier. So A.
Comment: Expedited retrievals allow you to quickly access your data that's stored in the S3 Glacier Flexible Retrieval storage class or the S3 Intelligent-Tiering Archive Access tier when occasional urgent requests for restoring archives are required. Data accessed by using Expedited retrievals is typically made available within 1–5 minutes.
Comment: A for sure!
Comment: C because A is not the most cost effective
Comment: Expedited retrieval typically takes 1-5 minutes to retrieve data, making it suitable for the company's requirement of having the files available in a maximum of five minutes.
Comment: Glacier expedite
Comment: Answer - A Fast availability: Although retrieval times for objects stored in Amazon S3 Glacier typically range from minutes to hours, you can use the Expedited retrievals option to expedite access to your archives. By using Expedited retrievals, the files can be made available in a maximum of five minutes when needed. However, Expedited retrievals do incur higher costs compared to standard retrievals.
Comment: glacier expedited retrieval times of typically 1-5 minutes.
Comment: Fully agree. Check here for evidences: https://aws.amazon.com/s3/storage-classes/glacier/#:~:text=S3%20Glacier%20Flexible%20Retrieval%20provides,amounts%20of%20data%20typically%20in
Comment: ECS is slightly cheaper than EKS
Comment: B: CloudFront = Extra cost for something they don't want (CDN) C: Kubernetes is more operationally complex than ECS containers on Fargate. D: EC2 expensive A: S3 is cheap for static content. ECS with Fargate is easiest implantation. Managed RDS is very low op overhead
Comment: Why not B ?
Comment: Aaa I got it. With CF we are adding additional cost => A.
Comment: A is better because ECS Fargate = "containerized application"
Comment: Use Amazon S3 to host static content. Use Amazon Elastic Container Service (Amazon ECS) with AWS Fargate for compute power. Use a managed Amazon RDS cluster for the database.
Comment: S3= hosting static contents Ecs = Little cheaper than EKS RDS = Database
Comment: Use Amazon S3 to host static content. Use Amazon Elastic Container Service (Amazon ECS) with AWS Fargate for compute power. Use a managed Amazon RDS cluster for the database
Comment: Amazon S3 is a highly scalable and cost-effective storage service that can be used to host static website content. It provides durability, high availability, and low latency access to the static files. Amazon ECS with AWS Fargate eliminates the need to manage the underlying infrastructure. It allows you to run containerized applications without provisioning or managing EC2 instances. This reduces operational overhead and provides scalability. By using a managed Amazon RDS cluster for the database, you can offload the management tasks such as backups, patching, and monitoring to AWS. This reduces the operational burden and ensures high availability and durability of the database.
Comment: The other options are incorrect for the following reasons: A. Amazon FSx Multi-AZ deployments Amazon FSx is a managed file system service that provides access to file systems that are hosted on Amazon EC2 instances. Amazon FSx does not support native protocols, such as NFS. B. Amazon Elastic Block Store (Amazon EBS) Multi-Attach volumes Amazon EBS is a block storage service that provides durable, block-level storage volumes for use with Amazon EC2 instances. Amazon EBS Multi-Attach volumes can be attached to multiple EC2 instances at the same time, but they cannot be mounted by multiple Linux instances through native protocols, such as NFS. D. Amazon Elastic File System (Amazon EFS) with a single mount target and multiple access points A single mount target can only be used to mount the file system on a single EC2 instance. Multiple access points are used to provide access to the file system from different VPCs.
Comment: Amazon FSx ONTAP supports clients mounting it with NFS. https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/attach-linux-client.html. Though A is not clear about which FSx product is used
Comment: "A single mount target can only be used to mount the file system on a single EC2 instance. Multiple access points are used to provide access to the file system from different VPCs." This is clearly wrong. You can have exactly one EFS mount target per subnet (AZ), and of course this mount target can be used by many clients (EC2 instances, containers etc.) - see diagram here for example: https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html In my opinion, C and D are equally valid answers.
Comment: Amazon EFS is a fully managed file system service that provides scalable, shared storage for Amazon EC2 instances. It supports the Network File System version 4 (NFSv4) protocol, which is a native protocol for Linux-based systems. EFS is designed to be highly available, durable, and scalable.
Comment: A: FSx is a File Server, not a mountable file system B: EBS can't be mounted on on-prem devices D: Access points are not same as mount points C: EFS support multi mount targets and on-prem devices: https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-mount-helper-direct.html
Comment: EFS POSIX LINUX
Comment: C. Amazon Elastic File System (Amazon EFS) with multiple mount targets
Comment: i don't understand why not D?
Comment: the requirement is mountable by multiple Linux -> C (multiple mount targets)
Comment: Service Control Policies (SCP): SCPs are an integral part of AWS Organizations and allow you to set fine-grained permissions on the organizational units (OUs) within your AWS Organization. SCPs provide central control over the maximum permissions that can be granted to member accounts, including the root user. Denying Access to Billing Information: By creating an SCP and attaching it to the root OU, you can explicitly deny access to billing information for all accounts within the organization. SCPs can be used to restrict access to various AWS services and actions, including billing-related services. Granular Control: SCPs enable you to define specific permissions and restrictions at the organizational unit level. By denying access to billing information at the root OU, you can ensure that no member accounts, including root users, have access to the billing information.
Comment: but SCP do not apply to the management account (full admin power)?
Comment: i can understand this information coming from the famous course in udemy. I tought same, but after some research i now think it is a wrong information. "SCPs affect all users and roles in attached accounts, including the root user. The only exceptions are those described in Tasks and entities not restricted by SCPs." https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#:~:text=SCPs%20affect%20all%20users%20and,affect%20any%20service%2Dlinked%20role.
Comment: SCP is for authorization
Comment: C. Create a service control policy (SCP) to deny access to the billing information. Attach the SCP to the root organizational unit (OU)
Comment: C Crt 100%
Comment: Service control policy are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization's access control guidelines. SCPs are available only in an organization that has all features enabled.
Comment: By denying access to billing information at the root OU, you can ensure that no member accounts, including root users, have access to the billing information.
Comment: c for me
Comment: "Configuring an Amazon SNS dead-letter queue for a subscription ... A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully", this is exactly what C says. https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html B, an SQS queue "between the application and Amazon SNS" would change the application logic. SQS cannot push messages to the "on-premises https endpoint", rather the destination would have to retrieve messages from the queue. Besides, option B would eventually deliver the messages that failed on the first attempt, which is NOT what is asked for. The goal is to retain undeliverable messages for analysis (NOT to deliver them), and this is typically achieved with a dead letter queue.
Comment: A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully.https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html
Comment: LEAST development effort! A: Custom dead letter queue using Kinesis Data Stream (laughable solution!) so lots of coding B: Change app logic to put SQS between SNS and the app. Also too much coding D: Same as A, too much code change C: SNS dead letter queue is by default a SQS que so no coding required
Comment: Problem here SNS dead letter queue is a SQS queue, so technically speaking both B and C are right. But I suppose that they want us to speak about SNS dead letter queue, that nobody do... meh, frustrating.
Comment: Aaaah ok. So with B == you place the SQS queue between the application and the SNS topic with C == you place the SQS queue as a DLQ for the SNS topic Of course it's C !
Comment: https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html
Comment: GPT4 to the rescue: The most appropriate solution would be to configure an Amazon SNS dead letter queue with an Amazon Simple Queue Service (Amazon SQS) target with a retention period of 14 days (Option C). This setup would ensure that any undelivered messages are retained in the SQS queue for up to 14 days for analysis, with minimal development effort required.
Comment: ChatGPT is not a reliable source.
Comment: I like (B) since it is put SQS before SNS so we could prepare for retention. (C) dead letter Queue is kind of "rescue" effort. Also (C) should mention reprocessing dead letter.
Comment: "Reprocessing dead letters" is not desired here. They want to "retain messages that are not delivered and analyze the messages for up to 14 days", which is what C does.
Comment: C is correct. It used a combination of SNS and SQS so it better than B.
Comment: C is the answer
Comment: B is correct Answer. SQS Retain messages in queues for up to 14 days C is incorrect because there is nothing called Amazon SNS dead letter queue
Comment: https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html
Comment: C "Configure an Amazon SNS dead letter queue" AWS "Configuring an Amazon SNS dead-letter queue" https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html
Comment: https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html
Comment: C. Configure an Amazon SNS dead letter queue that has an Amazon Simple Queue Service (Amazon SQS) target with a retention period of 14 days. By using an Amazon SQS queue as the target for the dead letter queue, you ensure that the undelivered messages are reliably stored in a queue for up to 14 days. Amazon SQS allows you to specify a retention period for messages, which meets the retention requirement without additional development effort.
Comment: Dead Letter is a SQS feature not SNS. A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing. For more information, see Configuring an Amazon SNS dead-letter queue for a subscription and Amazon SNS message delivery retries. https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html
Comment: "See Configuring an Amazon SNS (!) dead-letter queue", exactly, thus C.
Comment: In SNS, DLQs store the messages that failed to be delivered to subscribed endpoints. For more information, see Amazon SNS Dead-Letter Queues. In SQS, DLQs store the messages that failed to be processed by your consumer application. This failure mode can happen when producers and consumers fail to interpret aspects of the protocol that they use to communicate. In that case, the consumer receives the message from the queue, but fails to process it, as the message doesn't have the structure or content that the consumer expects. The consumer can't delete the message from the queue either. After exhausting the receive count in the redrive policy, SQS can sideline the message to the DLQ. For more information, see Amazon SQS Dead-Letter Queues. https://aws.amazon.com/blogs/compute/designing-durable-serverless-apps-with-dlqs-for-amazon-sns-amazon-sqs-aws-lambda/
Comment: "Configuring an Amazon SNS dead-letter queue for a subscription A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. "
Comment: C is best to handle this requirement. Although good to note that dead-letter queue is an SQS queue. "A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing." https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html#:~:text=A%20dead%2Dletter%20queue%20is%20an%20Amazon%20SQS%20queue
Comment: C - Amazon SNS dead letter queues are used to handle messages that are not delivered to their intended recipients. When a message is sent to an Amazon SNS topic, it is first delivered to the topic's subscribers. If a message is not delivered to any of the subscribers, it is sent to the topic's dead letter queue. Amazon SQS is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. Amazon SQS queues can be configured to have a retention period, which is the amount of time that messages will be kept in the queue before they are deleted. To meet the requirements of the company, you can configure an Amazon SNS dead letter queue that has an Amazon SQS target with a retention period of 14 days. This will ensure that any messages that are not delivered to the on-premises warehouse application will be stored in the Amazon SQS queue for up to 14 days. The company can then analyze the messages in the Amazon SQS queue to determine why they were not delivered.
Comment: https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html
Comment: Continuous backups is a native feature of DynamoDB, it works at any scale without having to manage servers or clusters and allows you to export data across AWS Regions and accounts to any point-in-time in the last 35 days at a per-second granularity. Plus, it doesn't affect the read capacity or the availability of your production tables. https://aws.amazon.com/blogs/aws/new-export-amazon-dynamodb-table-data-to-data-lake-amazon-s3/
Comment: A: Impacts RCU C: Requires coding of Lambda to read from stream to S3 D: More coding in Lambda B: AWS Managed solution with no coding
Comment: DynamoDB export to S3 is a fully managed solution for exporting DynamoDB data to an Amazon S3 bucket at scale.
Comment: A DynamoDB stream is an ordered flow of information about changes to items in a DynamoDB table… for C.U.D events ( Create, Update, Delete) and its logs are retained for only 24hrs .
Comment: Export the data directly from DynamoDB to Amazon S3 with continuous backups. Turn on point-in-time recovery for the table.
Comment: continous backup, no impact to availability ==> DynamoDB stream B. export is one off, noy continuous and demand on read capacity
Comment: minimal amount of coding rules out Lambda
Comment: ChatGpt answer is C and it indicates continuous backup process uses DynamoDB stream actually
Comment: Wrong. "DynamoDB full exports are charged based on the size of the DynamoDB table (table data and local secondary indexes) at the point in time for which the export is done. DynamoDB incremental exports are charged based on the size of data processed from your continuous backups for the time period being exported." https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataExport.HowItWorks.html
Comment: ChatGPT is usually wrong on these topics.
Comment: Using DynamoDB table export, you can export data from an Amazon DynamoDB table from any time within your point-in-time recovery window to an Amazon S3 bucket. Exporting a table does not consume read capacity on the table, and has no impact on table performance and availability.
Comment: https://repost.aws/knowledge-center/back-up-dynamodb-s3 https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-continuous-backups-and-point-in-time-recovery-pitr/ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.html There is no edit
Comment: Continuous Backups: DynamoDB provides a feature called continuous backups, which automatically backs up your table data. Enabling continuous backups ensures that your table data is continuously backed up without the need for additional coding or manual interventions. Export to Amazon S3: With continuous backups enabled, DynamoDB can directly export the backups to an Amazon S3 bucket. This eliminates the need for custom coding to export the data. Minimal Coding: Option B requires the least amount of coding effort as continuous backups and the export to Amazon S3 functionality are built-in features of DynamoDB. No Impact on Availability and RCUs: Enabling continuous backups and exporting data to Amazon S3 does not affect the availability of your application or the read capacity units (RCUs) defined for the table. These operations happen in the background and do not impact the table's performance or consume additional RCUs.
Comment: DynamoDB Export to S3 feature Using this feature, you can export data from an Amazon DynamoDB table anytime within your point-in-time recovery window to an Amazon S3 bucket.
Comment: B also for me
Comment: https://repost.aws/knowledge-center/back-up-dynamodb-s3 https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-continuous-backups-and-point-in-time-recovery-pitr/ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.html
Comment: you could mention what is the best answer from you :)
Comment: SQS FIFO is slightly more expensive than standard queue https://calculator.aws/#/addService/SQS I would still go with the standard because of the keyword "at least once" because FIFO process "exactly once". That leaves us with A and D, I believe that lambda function only needs to decrypt so I would choose A
Comment: "Process each request at least once" = Standard queue, rules out B and C which use more expensive FIFO queue Permissions are added to Lambda execution roles, not Lambda functions, thus D is out.
Comment: Use AWS Lambda event source mapping. Set Amazon Simple Queue Service (Amazon SQS) standard queues as the event source. Use AWS Key Management Service (SSE-KMS) for encryption. Add the kms permission for the Lambda execution role.
Comment: D is not FIFO either
Comment: With the SSE-SQS encryption type, you do not need to create, manage, or pay for SQS-managed encryption keys.
Comment: And what the hell is "encryption key invocation permission for the Lambda function"?
Comment: Initially though it is B, but it is said that the messages should be processed at lest once, not the same order, and Standard SQS is "almost" FIFO, which changed my opinion and I would go with A as correct.
Comment: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html
Comment: Using SQS FIFO queues ensures each message is processed at least once in order. SSE-SQS provides encryption that is handled entirely by SQS without needing decrypt permissions. Standard SQS queues (Options A and D) do not guarantee order. Using KMS keys (Options C and D) requires providing the Lambda role with decrypt permissions, adding complexity. SQS FIFO queues with SSE-SQS encryption provide orderly, secure, server-side message processing that Lambda can consume without needing to manage decryption. This is the most efficient and cost-effective approach.
Comment: Amazon SQS offers standard as the default queue type. Standard queues support a nearly unlimited number of API calls per second, per API action (SendMessage, ReceiveMessage, or DeleteMessage). Standard queues support at-least-once message delivery. However, occasionally (because of the highly distributed architecture that allows nearly unlimited throughput), more than one copy of a message might be delivered out of order. Standard queues provide best-effort ordering which ensures that messages are generally delivered in the same order as they're sent.Whereas, FIFO (First-In-First-Out) queues have all the capabilities of the standard queues, but are designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can't be tolerated. ( is correct)
Comment: But permissions are added to Lambda execution roles, not functions
Comment: Least Privilege Policy leads to A over D.
Comment: Considering this is credit card validation process, there needs to be a strict 'process exactly once' policy offered by the SQS FIFO, and also SQS already supports server-side encryption with customer-provided encryption keys using the AWS Key Management Service (SSE-KMS) or using SQS-owned encryption keys (SSE-SQS). Both encryption options greatly reduce the operational burden and complexity involved in protecting data. Additionally, with the SSE-SQS encryption type, you do not need to create, manage, or pay for SQS-managed encryption keys. Therefore option B stands out for me.
Comment: I retract my answer and change it to A, there is a requirement to process each request 'at least once'. Only standard queues can deliver messages at least once. There is also a requirement for the most 'cost-effective' option. Standard queues are the cheaper option. https://aws.amazon.com/sqs/pricing/#:~:text=SQS%20requests%20priced%3F
Comment: https://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-least-privilege-policy.html
Comment: at least once and cost effective suggests SQS standard
Comment: Solution B is the most cost-effective solution to meet the requirements of the application. Amazon Simple Queue Service (SQS) FIFO queues are a good choice for this application because they guarantee that messages are processed in the order in which they are received. This is important for credit card data validation because it ensures that fraudulent transactions are not processed before legitimate transactions. SQS managed encryption keys (SSE-SQS) are a good choice for encrypting the messages in the SQS queue because they are free to use. AWS Key Management Service (KMS) keys (SSE-KMS) are also a good choice for encrypting the messages, but they do incur a cost.
Comment: "They guarantee that messages are processed in the order in which they are received. This is important" but not asked for!
Comment: AAAAAAAA
Comment: should be A. Key word - at least once and cost effective suggests SQS standard
Comment: It has to be default, no FIFO. It doesnt say just one, it says at least once, so that is default queue that is cheaper than FIFO. Between the default options, nto sure to be honest
Comment: No, when it comes to "credit card data validation," it should be FIFO. If you use the standard approach, there is a chance that people who come after will get processed before those who come first.
Comment: Question clearly says "process each request at least once" which is the description of a standard queue. Your opinion how these transactions should be processed does not matter if it contradicts the requirements given. Besides, it is about "credit card data validation", NOT payments. Nothing happens if they check twice is your credit card is valid.
Comment: I guess A
Comment: This solution uses standard queues in Amazon SQS, which are less expensive than FIFO queues. It also uses AWS Key Management Service (SSE-KMS) for encryption, which is a cost-effective way to encrypt data at rest and in transit. The kms:Decrypt permission is added to the Lambda execution role to allow it to decrypt messages from the queue
Comment: Anytime you see Multiple AWS Accounts, and needs to consolidate is AWS Organization. Also anytime we need to restrict anything in an organization, it is SCP policies.
Comment: IN MY EXAM
Comment: B. Multiple AWS account, consolidate under one AWS Organization, top down policy (SCP) to all member account to restrict EC2 Type.
Comment: Use AWS Organizations to organize the accounts into organizational units (OUs). Define and attach a service control policy (SCP) to control the usage of EC2 instance types.
Comment: I have a question regarding this answer, what do they mean by "development effort"?: If they mean the work it takes to implement the solution (using develop as implement), option B achieves the constraint with little administrative overhead (there is less to do to configure this option). If by "development effort", they mean less effort for the development team, when development team try to deploy instances and gets errors because they are not allowed, this generates overhead. In this case the best option is D. What did you think?
Comment: "Development effort" = Develop the solution that the question asks for. We don't care about the developers whose permissions we want to restrict.
Comment: Use AWS Organizations to organize the accounts into organizational units (OUs). Define and attach a service control policy (SCP) to control the usage of EC2 instance types
Comment: BBBBBBBBB
Comment: I would choose B The other options would require some level of programming or custom resource creation: A. Developing Systems Manager templates requires development effort C. Configuring EventBridge rules and Lambda functions requires development effort D. Creating Service Catalog products requires development effort to define the allowed EC2 configurations. Option B - Using Organizations service control policies - requires no custom development. It involves: Organizing accounts into OUs Creating an SCP that defines allowed/disallowed EC2 instance types Attaching the SCP to the appropriate OUs This is a native AWS service with a simple UI for defining and managing policies. No coding or resource creation is needed. So option B, using Organizations service control policies, will meet the requirements with the least development effort.
Comment: AWS Organizations: AWS Organizations is a service that helps you centrally manage multiple AWS accounts. It enables you to group accounts into organizational units (OUs) and apply policies across those accounts. Service Control Policies (SCPs): SCPs in AWS Organizations allow you to define fine-grained permissions and restrictions at the account or OU level. By attaching an SCP to the development accounts, you can control the creation and usage of EC2 instance types. Least Development Effort: Option B requires minimal development effort as it leverages the built-in features of AWS Organizations and SCPs. You can define the SCP to restrict the use of oversized EC2 instance types and apply it to the appropriate OUs or accounts.
Comment: B for me as well
Comment: Amazon Transcribe will convert the audio recordings into text, Amazon Translate will translate the text into English, and Amazon Comprehend will perform sentiment analysis on the translated text to generate sentiment analysis reports.
Comment: A: Comprehend cannot translate B: Lex is like a chatbot so not useful C: Polly converts text to audio (polly the parrot!) so this is wrong D: Can convert audio to text E: Can translate F: Can do sentiment analysis reports
Comment: It is: DEF
Comment: D. Use Amazon Transcribe to convert the audio recordings in any language into text. E. Use Amazon Translate to translate text in any language to English. F. Use Amazon Comprehend to create the sentiment analysis reports.
Comment: Amazon Transcribe to convert speech to text. Amazon Translate to translate text to english. Amazon Comprehend to perform sentiment analysis on translated text.
Comment: afree with DEF
Comment: I'd go with DEF too
Comment: agree with DEF
Comment: agreed as well, weird
Comment: @efren - It is not weird - This need to know the services for it
Comment: I ran a Policy Simulator and indeed, D is right answer. Here is the JSON policy: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:TerminateInstances", "Resource": "*" }, { "Effect": "Deny", "Action": "ec2:TerminateInstances", "Condition": { "NotIpAddress": { "aws:SourceIp" : [ "192.0.2.0/24", "203.0.113.0/24" ] } }, "Resource": "*" } ] }
Comment: The condition operator is "NotIpAddress" so I am not sure about D as right answer.
Comment: Deny when IP address is not in (NotIPAddress). AWS has a weird way of stating Deny and it almost sound like double negative meaning positive. But read this doc for more clarity: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html It has the exact same example! Good luck!
Comment: If you want to read more about this, see how it works: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html Same policy as in this question with almost same use case. D is correct answer.
Comment: the command is coming from a source IP which is not in the allowed range.
Comment: " aws:SourceIP " indicates the IP address that is trying to perform the action.
Comment: d for sure
Comment: PII or sensitive data = Macie
Comment: Configure Amazon Macie to run a data discovery job that uses managed identifiers for the required data types.
Comment: Amazon Macie is a data security service that uses machine learning (ML) and pattern matching to discover and help protect your sensitive data.
Comment: Macie = Sensitive PII
Comment: agree with C
Comment: Amazon Macie is a service that helps discover, classify, and protect sensitive data stored in AWS. It uses machine learning algorithms and managed identifiers to detect various types of sensitive information, including personally identifiable information (PII) and financial information. By configuring Amazon Macie to run a data discovery job with the appropriate managed identifiers for the required data types (such as passport numbers and credit card numbers), the company can identify and classify any sensitive data present in the S3 bucket.
Comment: By combining the deployment of an AWS Storage Gateway file gateway and an AWS Storage Gateway volume gateway, the company can address both its block storage and NFS storage needs, while leveraging local caching capabilities for improved performance.
Comment: A: Not possible C: Snowball edge is snowball with computing. It's not a NAS! E: Technically yes but requires VPN or Direct Connect so re-architecture B & D both use Storage Gateway which can be used as NFS and Block storage https://aws.amazon.com/storagegateway/
Comment: Use the Storage Gateway -> It means that use S3 for storage ?
Comment: DE B is not correct be cause NFS is a file system while storage gw is a storage. To replace a file system, need another file system which is EFS.
Comment: if you focus on the wording of option B its "Storage gateway File gateway" not volume gateway hence it is perfect replacement for NFS files.
Comment: That's what i thought. but I think B is work too.
Comment: Deploy an AWS Storage Gateway file gateway to replace NFS storage Deploy an AWS Storage Gateway volume gateway to replace the block storage
Comment: local caching is a key feature of AWS Storage Gateway solution https://aws.amazon.com/storagegateway/features/ https://aws.amazon.com/blogs/storage/aws-storage-gateway-increases-cache-4x-and-enhances-bandwidth-throttling/#:~:text=AWS%20Storage%20Gateway%20increases%20cache%204x%20and%20enhances,for%20Volume%20Gateway%20customers%20...%205%20Conclusion%20
Comment: B and D is the correct answer
Comment: A VPC gateway endpoint allows you to privately access Amazon S3 from within your VPC without using a NAT gateway or NAT instance. By provisioning a VPC gateway endpoint for S3, the service in the private subnet can directly communicate with S3 without incurring data transfer costs for traffic going through a NAT gateway.
Comment: As a rule of thumb, EC2<->S3 in your workload should always try to use a VPC gateway unless there is an explicit restriction (account etc.) which disallows it.
Comment: Using a VPC endpoint for S3 allows the EC2 instances to access S3 directly over the Amazon network without traversing the internet. This significantly reduces data output charges.
Comment: use VPC gateway endpoint to route traffic internally and save on costs.
Comment: private subnet needs to communicate with S3 --> VPC endpoint right away
Comment: S3 Lifecycle policies allow you to define rules that automatically transition or expire objects based on their age or other criteria. By configuring an S3 Lifecycle policy to delete expired object versions and retain only the two most recent versions, you can effectively manage the storage costs while maintaining the desired retention policy. This solution is highly automated and requires minimal operational overhead as the lifecycle management is handled by S3 itself.
Comment: B: Too much work with Lambda C: Possible but requires lot of work D: Oxymoron statement... i.e. how do you remove version and retain version at same time without additional overhead? Custom solution may be more work. A: S3 Lifecycle is designed to retain object and version with set criteria
Comment: Use S3 Lifecycle to delete expired object versions and retain the two most recent versions.
Comment: S3 Lifecycle to the rescue...whoooosh
Comment: A --> "you can also provide a maximum number of noncurrent versions to retain." https://docs.aws.amazon.com/AmazonS3/latest/userguide/intro-lifecycle-rules.html
Comment: A is correct.
Comment: Agree with LONGMEN
Comment: Hosted Connection 50 Mbps, 100 Mbps, 200 Mbps, Dedicated Connection 1 Gbps, 10 Gbps, and 100 Gbps
Comment: No, you cannot directly adjust the speed of an existing Direct Connect connection through the AWS Management Console. To adjust the speed of an existing Direct Connect connection, you typically need to contact your Direct Connect service provider. They can assist you in modifying the speed of your connection based on your requirements. Depending on the provider, this process may involve submitting a request or contacting their support team to initiate the necessary changes. Keep in mind that adjusting the speed of your Direct Connect connection may also involve contractual and billing considerations.
Comment: A: Not secure as sharing with another account B: I don't think this possible as you need ISP to setup Direct Connect C: Less secure due to sharing D: Direct connect partners can provide hosted solutions for existing accounts so correct answer
Comment: For B I'm wrong above, it's because you cannot order 200MB connection through management console.
Comment: < 1 Gbps = Hosted (through partner)
Comment: If you already have an existing AWS Direct Connect connection configured at 1 Gbps, and you wish to reduce the connection bandwidth to 200 Mbps to minimize costs, you should indeed contact your AWS Direct Connect Partner and request to lower the connection speed to 200 Mbps.
Comment: I meant D.. DDDDDDDDDD
Comment: BBBBBBBBBBBBBB
Comment: company need to setup a cheaper connection (200 M) but B is incorrect because you can only order port speeds of 1, 10, or 100 Gbps for more flexibility you can go with hosted connection, You can order port speeds between 50 Mbps and 10 Gbps. https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html
Comment: By opting for a lower capacity 200 Mbps connection instead of the 1 Gbps connection, the company can significantly reduce costs. This solution ensures a dedicated and secure connection while aligning with the company's low utilization, resulting in cost savings.
Comment: But 200M cannot be ordered through Management Console, only partners.
Comment: D For Dedicated Connections, 1 Gbps, 10 Gbps, and 100 Gbps ports are available. For Hosted Connections, connection speeds of 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps and 10 Gbps may be ordered from approved AWS Direct Connect Partners. See AWS Direct Connect Partners for more information.
Comment: A hosted connection is a lower-cost option that is offered by AWS Direct Connect Partners
Comment: Also, there are not 200 MBps direct connection speed.
Comment: Hosted Connection 50 Mbps, 100 Mbps, 200 Mbps, Dedicated Connection 1 Gbps, 10 Gbps, and 100 Gbps B would require the company to purchase additional hardware or software
Comment: A This option involves deploying DataSync agents on your on-premises file servers and using DataSync to transfer the data directly to the FSx for Windows File Server. DataSync ensures that file permissions are preserved during the migration process. D This option involves using an AWS Snowcone device, a portable data transfer device. You would connect the Snowcone device to your on-premises network, launch DataSync agents on the device, and schedule DataSync tasks to transfer the data to FSx for Windows File Server. DataSync handles the migration process while preserving file permissions.
Comment: B, C and E would copy the files to S3 first where permissions would be lost
Comment: Why not - BD?
Comment: ° This option uses S3 as an intermediary, ensuring that file permissions are preserved during the initial data copy. DataSync can then transfer the data from S3 to FSx while maintaining the permissions. ° This option uses a Snowcone device with DataSync agents to replicate the on-premises permission structure directly to FSx. This approach is suitable for maintaining file permissions during migration.
Comment: B copies the data to S3 first where file permissions would be lost.
Comment: the key is file permissions are preserved during the migration process. only datasync supports that
Comment: Bro,all 5 answers mentioned Datasync.....
Comment: Yes but AD have only DataSync, whereas others have others have AWS CLI used.
Comment: Option B would require copy the data to Amazon S3 before transferring it to Amazon FSx for Windows File Server Option C would require the company to remove the drives from each file server and ship them to AWS
Comment: Also, S3 doesn't retain permissions because it isn't a file system.
Comment: Kinesis Data Firehose is near real time (min. 60 sec). - The question is focusing on real time processing/analysis + efficiency -> Kinesis Data Stream is real time ingestion. https://www.amazonaws.cn/en/kinesis/data-firehose/#:~:text=Near%20real%2Dtime,is%20sent%20to%20the%20service.
Comment: Unless the intention is real time analytics not real time ingestion !
Comment: By leveraging the combination of Amazon Kinesis Data Firehose and Amazon Kinesis Data Analytics, you can efficiently ingest and analyze the payment data in real time without the need for manual processing or additional infrastructure management. This solution provides a streamlined and scalable approach to handle continuous data ingestion and analysis requirements.
Comment: Kinesis Firehouse = ingesting Kinesis Datastreams = storing Kinesis analytics = doing analysis
Comment: Data is stored on S3 so real-time data analytics can be done with Kinesis Data Analytics which rules out Lambda solutions (A and D) as they are more operationally complex. B is not useful it is more of ETL. Firehose is actually to distribute data but given that company is already receiving data somehow so Firehose can basically distribute it to S3 with minimum latency. I have to admit this was confusing. I would have used Kinesis Streams to store on S3 and Data Analytics but combination is confusing!
Comment: "Data is stored on S3..." Nope. Re-read the first sentence. S3 is the destination, not the source. The task is to ingest, analyze in real time, and store in S3.
Comment: "payment data every minute on average" is a good-to-go- for firehose. Also firehose is more operational efficient compared to Data Streams.
Comment: I think this is A. The purpose of Firehose is to ingest and deliver to a data store, no to an analytics service. And in fact you can use lambda for real time analysis, such I find A more aligned.
Comment: But developing and maintaining a custom Lambda function "to analyze the data in real time" is surely not as 'operationally efficient' as using an existing service such as Kinesis Data Analytics.
Comment: Firehose has a 60 sec delay so real time analytics should be without real time data isn't that problematic? Why would you have then real time analytics then in the first place?
Comment: Kinesis Data Streams focuses on ingesting and storing data streams while Kinesis Data Firehose focuses on delivering data streams to select destinations, as the motive of the question is to do analytics, the answer should be C.
Comment: Kinesis Data Streams focuses on ingesting and storing data streams while Kinesis Data Firehose focuses on delivering data streams to select destinations, as the motive of the question is to do analytics, the answer should be C.
Comment: Quote “Connect with 30+ fully integrated AWS services and streaming destinations such as Amazon Simple Storage Service (S3)” at https://aws.amazon.com/kinesis/data-firehose/ . Amazon Kinesis Data Analystics https://aws.amazon.com/kinesis/data-analytics/
Comment: Use Kinesis Firehose to capture and deliver the data to Kinesis Analytics to perform analytics.
Comment: Did anyome took tge exam recently, How many questiona were there
Comment: Can we understand why admin's answers are mostly wrong? Or is this done on purpose?
Comment: Amazon Kinesis Data Firehose the most optimal variant
Comment: Shouldn't C be more appropriate?
Comment: You're right. I believe the answers are wrong on purpose, so good thing votes can be made on answers and discussions are allowed.
Comment: By combining the use of Amazon EFS for shared file storage and Amazon CloudFront for content delivery, you can achieve improved performance and resilience for the website.
Comment: First of all you should understand, a website using CMS is a dynamic one not static, so A is out, B is more complicated than C, so C, and between global accelerator and cloudfront, Cloudfront suits better as there is no legacy protocols data(UDP, etc) that needs to be accessed, hence E
Comment: I choose AE. Although I don't know if s3 can be mounted on ec2 ?? Maybe wrong wording. Efs is a better choice but its not a natural selection for strong images.
Comment: I made the same mistake but mounting S3 on EC2 is a painful operation so EFS makes more sense (C). Option E takes care of caching static images on CDN so that problem is solved along with resilience etc.
Comment: Not A because you can't mount an S3 bucket on an EC2 instance. You could use a file gateway and share an S3 bucket via NFS and mount that on EC2, but that is not mentioned here and would also not make sense.
Comment: it is possible to mount s3 to EC2, just quite difficult: https://aws.amazon.com/blogs/storage/mounting-amazon-s3-to-an-amazon-ec2-instance-using-a-private-connection-to-s3-file-gateway/
Comment: You can mount EFS file systems to multiple Amazon EC2 instances remotely and securely without having to log in to the instances by using the AWS Systems Manager Run Command.
Comment: A is out of the game for sure. Mount S3 to EC2 ... madness. The question is CE or DE, but it is CE because of AWS Global Accelerator is match with NLB, not ALB as it is staded in option D, thus CE as many of all here noted.
Comment: A and E is correct. We have a cloud fromt + S3 combo
Comment: S3 can't be mounted on EC2 it is not A for sure!
Comment: https://aws.amazon.com/blogs/storage/mounting-amazon-s3-to-an-amazon-ec2-instance-using-a-private-connection-to-s3-file-gateway/
Comment: "Using a ... S3 file gateway"
Comment: A and E. C is not correct because You dont mount a new EFS onto existing EC2. If you do that, you have to migrate all exising data in EBS into EFS. Then remove all the EBS. Should never do this.
Comment: I can't follow. EFS provides NFS mount points, how can you not mount those onto existing EC2?
Comment: https://bluexp.netapp.com/blog/ebs-efs-amazons3-best-cloud-storage-system
Comment: Not A - S3 cannot be mounted (up until few months ago). Exam does not test for the updates in last 6 months.
Comment: You have summarized the reasons why options A and E are the best choices very well. Migrating static website assets like images to Amazon S3 enables high scalability, durability and shared access across instances. This improves performance. Using Auto Scaling with load balancing provides elasticity and resilience. Adding a CloudFront distribution further boosts performance through caching and content delivery.
Comment: You can't directly mount an S3 bucket on EC2.
Comment: Both options AE and CE would work, but I choose AE, because, on my opinion, S3 is best suited for performance and resilience.
Comment: You can't directly mount an S3 bucket on EC2
Comment: EFS, unlike EBS, can be mounted across multiple EC2 instances and hence C over A.
Comment: Technically both options AE and CE would work. But S3 is best suited for unstructured data, and the key benefit of mounting S3 on EC2 is that it provides a cost-effective alternative of using object storage for applications dealing with large files, as compared to expensive file or block storage. At the same time it provides more performant, scalable and highly available storage for these applications. Even though there is no mention of 'cost efficient' in this question, in the real world cost is the no.1 factor. In the exam I believe both options would be a pass. https://aws.amazon.com/blogs/storage/mounting-amazon-s3-to-an-amazon-ec2-instance-using-a-private-connection-to-s3-file-gateway/
Comment: You can't directly mount an S3 bucket on EC2, only through file gateway
Comment: Option C provides moving the website images onto an Amazon EFS file system that is mounted on every EC2 instance. Amazon EFS provides a scalable and fully managed file storage solution that can be accessed concurrently from multiple EC2 instances. This ensures that the website images can be accessed efficiently and consistently by all instances, improving performance In Option E The Auto Scaling group maintains a minimum of two instances, ensuring resilience by automatically replacing any unhealthy instances. Additionally, configuring an Amazon CloudFront distribution for the website further improves performance by caching content at edge locations closer to the end-users, reducing latency and improving content delivery. Hence combining these actions, the website's performance is improved through efficient image storage and content delivery
Comment: Which answe is correct?the most voted ones or the Suggested answers?
Comment: the most voted always
Comment: A and E: S3 is perfect for images. Besides is the perfect partner of cloudfront
Comment: By having customers create an IAM role with the necessary permissions in their own accounts, the company can use AWS Identity and Access Management (IAM) to establish cross-account access. The trust policy allows the company's AWS account to assume the customer's IAM role temporarily, granting access to the specified resources (EC2 instances and CloudWatch metrics) within the customer's account. This approach follows the principle of least privilege, as the company only requests the necessary permissions and does not require long-term access keys or user credentials from the customers.
Comment: A. Roles give temporary credentials
Comment: Agreed . Role is the keyword
Comment: B: Sharing credentials, even temporary, is insecure C: Access and secret keys. That won't work and sharing secrets outside of account is not secure for this use case A: Keyword "trust policy" D: Again, sharing username and pwd and sharing in any way is not secure
Comment: Not B (would be about access to the company's account, not the customers' accounts) Not C (storing credentials in a custom system is a big nono) Not D (Cognito has nothing to do here and "user and password" is terrible)
Comment: The company's infrastructure monitoring service needs to call aws API's in the MOST secure way. So you have to focus on restricting access to the APIs and there is where cognito comes in to play.
Comment: What is unsecure with A?
Comment: The company runs an infrastructure monitoring service. Nowhere is stated that this service lives in an aws account. So A and C I wouldn't choose. B is a bit too vague. So I end up with D.
Comment: Are you suggesting to restrict CloudWatch API with Cognito roles?
Comment: A is the most secure approach for accessing customer accounts. Having customers create a cross-account IAM role with the appropriate permissions, and configuring the trust policy to allow the monitoring service principal account access, implements secure delegation and least privilege access.
Comment: The main difference between AWS Transit Gateway and VPC peering is that AWS Transit Gateway is designed to connect multiple VPCs together in a hub-and-spoke model, while VPC peering is designed to connect two VPCs together in a peer-to-peer model. As we have several VPCs here, the answer should be C.
Comment: AWS Transit Gateway is a highly scalable and centralized hub for connecting multiple VPCs, on-premises networks, and remote networks. It simplifies network connectivity by providing a single entry point and reducing the number of connections required. In this scenario, deploying an AWS Transit Gateway in the networking team's AWS account allows for efficient management and control over the network connectivity across multiple VPCs.
Comment: A: This option is suggesting hundreds of peering connection for EACH VPC. Nope! B: NAT gateway is for network translation not VPC interconnectivity so this is wrong C: Transit GW + static routes will connect all VPCs https://aws.amazon.com/transit-gateway/ D: VPN gateway is for on-prem to VPN for a VPC. There is no on-prem here so this is wrong
Comment: Connect, Monitor and Manage Multiple VPCs in one place = AWS Transit Gateway
Comment: C is the most operationally efficient solution for connecting a large number of VPCs across accounts. Using AWS Transit Gateway allows all the VPCs to connect to a central hub without needing to create a mesh of VPC peering connections between each VPC pair. This significantly reduces the operational overhead of managing the network topology as new VPCs are added or changed. The networking team can centrally manage the Transit Gateway routing and share it across accounts using Resource Access Manager.
Comment: Answer is C
Comment: A transit gateway is a network transit hub that you can use to interconnect your virtual private clouds (VPCs) and on-premises networks. As your cloud infrastructure expands globally, inter-Region peering connects transit gateways together using the AWS Global Infrastructure. Your data is automatically encrypted and never travels over the public internet.
Comment: I voted for c
Comment: An AWS Transit Gateway is a highly scalable and secure way to connect VPCs in multiple AWS accounts. It is a central hub that routes traffic between VPCs, on-premises networks, and AWS services.
Comment: Purchasing a 1-year Savings Plan (option A) or a 1-year Reserved Instance (option B) may provide cost savings, but they are more suitable for long-running, steady-state workloads. Since your batch jobs run for a specific period each day, using Spot Instances with the ability to scale out based on CPU usage is a more cost-effective choice.
Comment: C is the most cost-effective solution in this scenario. Using Spot Instances allows EC2 capacity to be purchased at significant discounts compared to On-Demand prices. The auto scaling group can scale out to add Spot Instances when needed for the batch jobs. If Spot Instances become unavailable, regular On-Demand Instances will be launched instead to maintain capacity. The potential for interruptions is acceptable since failed jobs can be re-run.
Comment: Stateless, most cost-effective >> Spot
Comment: You don't need any scaling really as the job runs on another EC2 instance if it fails on first one. A. B. D are all more expensive than C due to spot instance being cheaper than reserved instances.
Comment: Spot Instances to the rescue....whooosh
Comment: " If a job fails on one instance, another instance will reprocess the job". This ensures Spot Instances are enough for this case
Comment: Since your batch jobs run for a specific period each day, using Spot Instances with the ability to scale out based on CPU usage is a more cost-effective choice.
Comment: C FOR ME COS OF SPOT INSTACES
Comment: First I think it is B but because of cost saving I think it should be C spot instances.
Comment: c for me
Comment: This approach allows users to upload files directly to S3 without passing through the application servers, reducing the load on the application and improving scalability. It leverages the client-side capabilities to handle the file uploads and offloads the processing to S3.
Comment: C - You may use presigned URLs to allow someone to upload an object to your Amazon S3 bucket. Using a presigned URL will allow an upload without requiring another party to have AWS security credentials or permissions.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html "You can also use presigned URLs to allow someone to upload a specific object to your Amazon S3 bucket. This allows an upload without requiring another party to have AWS security credentials or permissions. "
Comment: S3 presigned url is used for sharing objects from an s3 bucket and not for uploading to an s3 bucket
Comment: No. It allows to download and upload. https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
Comment: C is the best solution to meet the scalability requirements. Generating S3 presigned URLs allows users to upload directly to S3 instead of application servers. This removes the application servers as a bottleneck for upload traffic. S3 can scale to handle very high volumes of uploads with no limits on storage or throughput. Using presigned URLs leverages this scalability.
Comment: You may use presigned URLs to allow someone to upload an object to your Amazon S3 bucket. Using a presigned URL will allow an upload without requiring another party to have AWS security credentials or permissions. https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html
Comment: Hello Moderator. This question and answer should be rephrased because: 1. S3 pre-signed URLs are used to share objects FROM S3 buckets 2. How scalable are pre-signed URLs when they are time constrained? https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
Comment: Both is wrong Presigned URLs can be used for upload The solution is scalable because you can issue thousands of pre-signed URLs, and thousands of users can upload images at the same time. User wants to upload picture -> server generates presigned URL and sends it to the app -> app uploads file
Comment: the most scalable because it allows users to upload files directly to Amazon S3,
Comment: Using DynamoDB's global tables feature, you can achieve a globally consistent reservation database with low latency on updates, making it suitable for serving a global user base. The automatic replication provided by DynamoDB eliminates the need for manual synchronization between Regions.
Comment: The question asks "Average latency must be less than 1 second on updates to the reservation database." A is incorrect: " Changes to a DynamoDB global tables are replicated asynchronously, with typical latency of between 0.5 - 2.5 seconds between AWS Regions in the same geographic area." B is the answer: "All Aurora Replicas return the same data for query results with minimal replica lag. This lag is usually much less than 100 milliseconds after the primary instance has written an update."
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html https://community.aws/content/2drxEND7MtTOb2bWs2J0NlCGewP/ddb-globaltables-lag?lang=en
Comment: How can you update your database in the different regions with read replicas? You need to be able to read and write to the database from the different regions.
Comment: Aurora: less than 1 second: https://aws.amazon.com/rds/aurora/global-database/ DynamoDB: from 0.5 to 2.5 second: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.html
Comment: B doesn't say Aurora Global
Comment: DynamoDB doesn't meet the <1s req though.
Comment: In my Opinion it is A. The reason is that Aurora Read Replicas support up to 5 Read replicas in different regions . We don't have that limitation with Dynamo DB Global tables, hence I vote for A.
Comment: Purely from the wording, seems B. DynamoDB "usually within one second" Aurora "usually less than one second" Question asks for "less than one second" thus Aurora
Comment: We need "a single primary reservation database that is globally consistent" -> A is out (DynamoDB is eventually consistent with "last writer wins" and "usually" updates "within [not: less than] one second"). D is out because it mentions multiple databases (and RDS Event Streams to not guarantee the order of events). C is out because RDS has higher replication delay, only Aurora can guarantee "less than one second". So we'd have "a single primary reservation database that is globally consistent" in one region, and we'd have read replicas with "less than 1 second on updates" latency in other regions.
Comment: "a web application for travel ticketing". This would be a transaction, so DynamoDB is not the answer.
Comment: So you can't write to DynamoDB tables at all because tables writes are transactions?
Comment: There are no assumptions about the application here. The choices are related to the database that has one primary source of truth but multi-region presence. No requirement for transaction is given or implied.
Comment: Dynamo DB global table acts as a single table. It does not consist of primary and standby databases. It is one single global table which is synchronously updated. Users can write to any of the regional endpoints and the write will be automatically updated across regions. To have a single primary database that is consistent does not align with dynamo db global tables. Option B is even more dumb compared to A since read replicas does not provide failover capability or fast updates from the primary database. The answer almost close to the requirement is Option A even though it is a misfit
Comment: The question mentions that the average latency on updates to the regional reservation databases should be less than 1sec. Read replicas provide asynchronous replication and hence the update times will be higher. Hence we can easily scrap all the options containing read replicas from the options. Moreover, a globally consistent database with millisecond latencies screams dynamo db global
Comment: I think the real difference is that DynamoDB is by default only eventually consistent however it has to be consistent. So it's B. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html " average latency less than 1 second."
Comment: This is for Cluster
Comment: Amazon DynamoDB global tables is a fully managed, serverless, multi-Region, and multi-active database. Global tables provide you 99.999% availability, increased application resiliency, and improved business continuity. As global tables replicate your Amazon DynamoDB tables automatically across your choice of AWS Regions, you can achieve fast, local read and write performance.
Comment: Amazon Aurora provides global databases that replicate your data with low latency to multiple regions. By using Aurora Read Replicas in each Region, the company can achieve low-latency access to the data while maintaining global consistency. The use of regional endpoints ensures that each deployment accesses the appropriate local replica, reducing latency. This solution allows the company to meet the requirement of serving a global user base while keeping average latency less than 1 second.
Comment: While Amazon DynamoDB is a highly scalable NoSQL database, using a global table might introduce latency and might not be suitable for maintaining a single primary reservation database with globally consistent data.
Comment: Aurora Global DB provides native multi-master replication and automatic failover for high availability across regions. Read replicas in each region ensure low read latency by promoting a local replica to handle reads. A single Aurora primary region handles all writes to maintain data consistency. Data replication and sync is managed automatically by Aurora Global DB. Regional endpoints minimize cross-region latency. Automatic failover promotes a replica to be the new primary if the current primary region goes down.
Comment: "the company must maintain a single primary reservation database that is globally consistent." --> Relational database, because it only allow writes from one regional endpoint DynamoDB global table allow BOTH reads and writes on all regions (“last writer wins”), so it is not single point of entry. You can set up IAM identity based policy to restrict write access for global tables that are not in NA but it is not mentioned.
Comment: Advantages of Amazon Aurora global databases By using Aurora global databases, you can get the following advantages: Global reads with local latency – If you have offices around the world, you can use an Aurora global database to keep your main sources of information updated in the primary AWS Region. Offices in your other Regions can access the information in their own Region, with local latency. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html D. although D is also using Aurora Global Database, there is no need for Lambda function to sync data.
Comment: In real life, I would use Aurora Global Database. Because 1. it achieve less than 1 sec latency, 2. And ticketing system is a very typical traditional relational system. While, in the exam I would vote for A. Because Option B isn't using global database which means you have to provide the endpoint of primary region to a remote region for update and even the typical back and forth latency is 400ms but you have to have a lot of professional network setup to guarantee it, which option B doesn't mention.
Comment: Option B suggests using an EC2-backed Amazon Machine Image (AMI) lifecycle policy to automate the backup process. By configuring the policy to run twice daily and specifying the copy to the us-west-2 Region, the company can ensure regular backups are created and copied to the alternate region. Option D proposes using AWS Backup, which provides a centralized backup management solution. By creating a backup vault and backup plan based on tag values, the company can automate the backup process for the EC2 instances. The backup schedule can be set to run twice daily, and the destination for the copy can be defined as the us-west-2 Region.
Comment: Both options automate the backup process and include copying the backups to the us-west-2 Region, ensuring data resilience in the event of a disaster. These solutions minimize administrative effort by leveraging automated backup and copy mechanisms provided by AWS services.
Comment: LEAST admin overhead: A: On demand so wrong C: Lambda is overhead E: On-demand is wrong BD is the only choice. Although D seems to cover for B also, happy to be corrected.
Comment: B D seems to meet the requiremnts fully
Comment: B and D are the options that meet the requirements with the least administrative effort. B uses EC2 image lifecycle policies to automatically create AMIs of the instances twice daily and copy them to the us-west-2 region. This automates regional backups. D leverages AWS Backup to define a backup plan that runs twice daily and copies backups to us-west-2. AWS Backup automates EC2 instance backups. Together, these options provide automated, regional EC2 backup capabilities with minimal administrative overhead.
Comment: options B and D will provide least administrative effort.
Comment: I also vote B and D.
Comment: solutions are both automated and require no manual intervention to create or copy backups
Comment: A wrong because security group can't deny (only allow)
Comment: In this scenario, the security audit reveals that the application is receiving millions of illegitimate requests from a small number of IP addresses. To address this issue, it is recommended to modify the network ACL (Access Control List) for the web tier subnets. By adding an inbound deny rule specifically targeting the IP addresses that are consuming resources, the network ACL can block the illegitimate traffic at the subnet level before it reaches the web servers. This will help alleviate the excessive load on the web tier and improve the application's performance.
Comment: A: Wrong as SG cannot deny. By default everything is deny in SG and you allow stuff CD: App tier is not under attack so these are irrelevant options B: Correct as NACL is exactly for this access control list to define rules for CIDR or IP addresses
Comment: Modify the network ACL for the web tier subnets. Add an inbound deny rule for the IP addresses that are consuming resources.
Comment: A is wrong Security groups act at the network interface level, not the subnet level, and they support Allow rules only.
Comment: The security Group can be applied to an ALB at web tier.
Comment: Security group can't deny.
Comment: Security group rules are always permissive; you can't create rules that deny access. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html
Comment: Since the bad requests are targeting the web tier, adding ACL deny rules for those IP addresses on the web subnets will block the traffic before it reaches the instances. Security group changes (Options A and C) would not be effective since the requests are not even reaching those resources. Modifying the application tier ACL (Option D) would not stop the bad traffic from hitting the web tier.
Comment: A is wrong because you cannot put any deny in security group
Comment: You cannot Deny on SG, so it's B
Comment: Option B is not as effective as option A
Comment: A and C out due to the fact that SG does not have deny on allow rules.
Comment: Security group only have allow rules
Comment: yeah, my mistake. B should be
Comment: Answer: C -->"You cannot reference the security group of a peer VPC that's in a different Region. Instead, use the CIDR block of the peer VPC." https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html
Comment: Wow, big thanks!
Comment: Thanks for this clarification!
Comment: "You cannot reference the security group of a peer VPC that's in a different Region. Instead, use the CIDR block of the peer VPC." https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html
Comment: After establishing the VPC peering connection, the subnet route tables need to be updated in both VPCs to route traffic to the other VPC's CIDR blocks through the peering connection.
Comment: VPC Peering Connection: This allows communication between instances in different VPCs as if they are on the same network. It's a straightforward approach to connect the two VPCs. Subnet Route Tables: After establishing the VPC peering connection, the subnet route tables need to be updated in both VPCs to route traffic to the other VPC's CIDR blocks through the peering connection. Inbound Rule in Database Security Group: By creating an inbound rule in the ap-southeast-2 database security group that allows traffic from the eu-west-1 application server IP addresses, you ensure that only the specified application servers from the eu-west-1 VPC can access the database servers in the ap-southeast-2 VPC.
Comment: B) Configure VPC peering between ap-southeast-2 and eu-west-1 VPCs. Update routes. Allow traffic in ap-southeast-2 database SG from eu-west-1 application server SG. This option establishes the correct network connectivity for the applications in eu-west-1 to reach the databases in ap-southeast-2: VPC peering connects the two VPCs across regions - https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html#:~:text=You%20can%20create%20a%20VPC,%2DRegion%20VPC%20peering%20connection). Updating route tables enables routing between the VPCs Security group rule allowing traffic from eu-west-1 application server SG to ap-southeast-2 database SG secures connectivity
Comment: No, you cannot use a SG reference from another region so last part "Create an inbound rule in the ap-southeast-2 database security group that references the security group ID of the application servers in eu-west-1" cannot be setup. This is why B is wrong.
Comment: Options A, C, D have flaws: Option A peer direction is wrong Option C opens databases to application server IP addresses rather than SG Option D uses transit gateway which is unnecessary for just two VPCs
Comment: Selected C but B can also work
Comment: I just tried from the the console, You can specify the name or ID of another security group in the same region. To specify a security group in another AWS account (EC2-Classic only), prefix it with the account ID and a forward slash, for example: 111122223333/OtherSecurityGroup. You can Specify a single IP address, or an IP address range in CIDR notation in the same/other region. In the exam both option B and C would be a pass. In the real world both option will work.
Comment: Correction, You cannot reference the security group of a peer VPC that's in a different Region. Instead, use the CIDR block of the peer VPC. The C is the only option here. https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html#:~:text=You%20cannot-,reference,-the%20security%20group
Comment: This is why B is wrong. You can never access cross region security group id
Comment: I realize D is right as ChatGpt indicates.Because here is not a problem just one application in a VPC connection to another in different region. Actually there many applications in different VPCs in a region which need to connect any other application crossingly in other region. So two transit gateway need to installed in two regions for multiple to multiple VPCs connections.
Comment: However, there was also a part of "create an inbound rule in the database security group that references the security group ID of the application servers in eu-west-1" therefore, still C because we cannot reference SG ID of diff VPC, we should use the CIDR block
Comment: post it on ChaptGpt and it give me answer D. what heck with this?
Comment: B is wrong because It is in a different region, so reference to the security group ID will not work. A is wrong because you need to update the route table. The answer should be C.
Comment: is B. what happens if application server IP addresses changes (Option C). You must change manually the IP in the security group again.
Comment: I thought B, but I vote C after checking Axeashes response.
Comment: I think the answer is C because the security groups are in different VPCs. When the question wants to allow traffic from app vpc to database vpc i think using peering connection you will be able to add the security groups rules using private ip addresses of app servers. I don't think the database VPC will identify the security group id of another VPC.
Comment: D You cannot create a VPC peering connection between VPCs in different regions.
Comment: You can peer any two VPCs in different Regions, as long as they have distinct, non-overlapping CIDR blocks https://docs.aws.amazon.com/devicefarm/latest/developerguide/amazon-vpc-cross-region.html
Comment: You can peer any two VPCs in different Regions, as long as they have distinct, non-overlapping CIDR blocks. This ensures that all of the private IP addresses are unique, and it allows all of the resources in the VPCs to address each other without the need for any form of network address translation (NAT).
Comment: b for me. bcs correct inbound rule, and not overhead
Comment: Option B suggests configuring a VPC peering connection between the ap-southeast-2 VPC and the eu-west-1 VPC. By establishing this peering connection, the VPCs can communicate with each other over their private IP addresses. Additionally, updating the subnet route tables is necessary to ensure that the traffic destined for the remote VPC is correctly routed through the VPC peering connection. To secure the communication, an inbound rule is created in the ap-southeast-2 database security group. This rule references the security group ID of the application servers in the eu-west-1 VPC, allowing traffic only from those instances. This approach ensures that only the authorized application servers can access the databases in the ap-southeast-2 VPC.
Comment: Option C suggests using Amazon Aurora On-Demand PostgreSQL-Compatible databases for each development environment. This option provides the benefits of Amazon Aurora, which is a high-performance and scalable database engine, while allowing you to pay for usage on an on-demand basis. Amazon Aurora On-Demand instances are typically more cost-effective for individual development environments compared to the provisioned capacity options.
Comment: Option B suggests using Amazon RDS for PostgreSQL Single-AZ DB instances for each development environment. While Amazon RDS is a reliable and cost-effective option, it may have slightly higher costs compared to Amazon Aurora On-Demand instances.
Comment: I'm thinking that it should be B, since question does not mention any requirement only cost effective and this is just an development environment I guess we can leverage the use of RDS free tier also
Comment: Guys, when you use the pricing calculator the cost between option B and C is really close. I doubt anyone wants to test on your knowledge of exact pricings in your region. I think that "On Demand" being explicitly specified in option C and not being specified in option B is the main difference here the exam wants to test. In that case I'd assume that option B means a constantly running instance and not "On Demand" which would make the choice pretty obvious. Again, I don't think AWS exam will test you on knowing that a single AZ is cheaper by 0,005 cents than Aurora :D
Comment: I choose C because Aurora on-Demand is Aurora Serverless: The Aurora Serverless is cost effective. Scale out fine-grained increments to provide just the right number of database resources and pay only for capacity consumed.
Comment: Single-AZ DB instances cheaper
Comment: Single AZ more cost effective
Comment: 1 instance(s) x 0.245 USD hourly x (4 / 24 hours in a day) x 730 hours in a month = 29.8083 USD ---> Amazon RDS PostgreSQL instances cost (monthly) 1 instance(s) x 0.26 USD hourly x (4 / 24 hours in a day) x 730 hours in a month = 31.6333 USD ---> Amazon Aurora PostgreSQL-Compatible DB instances cost (monthly)
Comment: C is correct because B is cheaper but they don't mention to stop the DB when not in use
Comment: On-Demand is cheaper that Aurora or RDS because of low weekly usage
Comment: We have environments that are used on average 4 hours per workday = 20 hours per week. So with option C (Aurora on-demand aka serverless) we pay for 20 hours per week. With option B (RDS) we pay for 168 hours per week (the answer does not mention anything about automating shutdown etc.). So even if Aurora Serverless is slightly more expensive than RDS, C is cheaper because we pay only 20 (not 168) hours per week.
Comment: Aurora on demand is (a little) more expensive than Aurora Aurora is more expensive than RDS single instance So cost effectiveness == RDS. (B)
Comment: But if you use the database only 20 hours per week (5 x 4), wouldn't you pay way less with Aurora serverless than with RDS?
Comment: AWS Services Calculator is showing B cheaper by less than a dollar for the same settings for both. I used "db.r6g.large" for RDS (Single-AZ) and Aurora and put 4 hours/day.
Comment: I used the calculator, single AZ is cheaper for the exact same usage duration, if you pick On-Demand option for it too. In Aurora case (option C) you have "On Demand" explicitly specified, so if it has to be specified then I suppose that B option is about a constantly running instance. If B had an "On Demand" added, I'd vote B too.
Comment: Amazon RDS Single AZ is cheaper than Aurora Multi-AZ
Comment: Aurora instances will cost you ~20% more than RDS MySQL Given the running hours the same. Also Aurora is HA.
Comment: … just trying to trick you. Aurora on demand is Aurora Serverless.
Comment: that is good piece of infroamtion
Comment: Aurora allows you to pay for the hours used. 4 hour every day, you only need 1/6 cost of 24 hours per day. You can check the Aurora pricing calculator.
Comment: The key factors: RDS Single-AZ instances only run the DB instance when in use, minimizing costs for dev environments not used full-time RDS charges by the hour for DB instance hours used, versus Aurora clusters that have hourly uptime charges PostgreSQL is natively supported by RDS so no compatibility issues S3 Object Select (Option D) does not provide full database functionality Aurora (Options A and C) has higher minimum costs than RDS even when not fully utilized
Comment: Aurora is FULLY compatible with PostgreSQL, allowing existing applications and tools to run without requiring modification. https://aws.amazon.com/rds/aurora/features/#:~:text=Aurora%20is%20fully%20compatible%20with,to%20run%20without%20requiring%20modification
Comment: Putting into consideration that the environments will only run 4 hours everyday and the need to save on costs, then Amazon Aurora would be suitable because it supports auto-scaling configuration where the database automatically starts up, shuts down, and scales capacity up or down based on your application's needs. So for the rest of the 4 hours everyday when not in use the database shuts down automatically when there is no activity. Option C would be best, as this is the name of the service from the aws console.
Comment: I will go for A. C and D doesn't make sense. B- resources not running? No
Comment: Use AWS config to deploy the tag rule and remediate resources that are not compliant.
Comment: This option has the least operational overhead: AWS Config continuously evaluates resource configurations and can identify untagged resources Resources can be programmatically tagged via the AWS SDK based on Config data Backup plans can use tag criteria to automatically back up newly tagged resources No manual review or resource discovery needed
Comment: Vote A
Comment: a valid for me
Comment: This solution allows you to leverage AWS Config to identify any untagged resources within your AWS Organizations accounts. Once identified, you can programmatically apply the necessary tags to indicate the backup requirements for each resource. By using tags in the backup plan configuration, you can ensure that only the tagged resources are included in the backup process, reducing operational overhead and ensuring all necessary resources are backed up.
Comment: By using Amazon S3 and AWS Lambda together, you can create a serverless architecture that provides highly scalable and available image resizing capabilities. Here's how the solution would work: Set up an Amazon S3 bucket to store the original images uploaded by users. Configure an event trigger on the S3 bucket to invoke an AWS Lambda function whenever a new image is uploaded. The Lambda function can be designed to retrieve the uploaded image, perform the necessary resizing operations based on device requirements, and store the resized images back in the S3 bucket or a different bucket designated for resized images. Configure the Amazon S3 bucket to make the resized images publicly accessible for serving to users.
Comment: How can end user upload an image to S3 bucket with static hosting. I believe it should be dynamic website (Answer D)
Comment: image = static = S3 or cloudfront but image is unstructured data so you dont store it in a relational database like RDS and Step Function is not for processing So A
Comment: This meets all the key requirements: S3 static website provides high availability and auto scaling to handle unpredictable traffic Lambda functions invoked from the S3 site can resize images on the fly Storing images in S3 buckets provides durability, scalability and high throughput Serverless approach with S3 and Lambda maximizes scalability and availability
Comment: Scalability = S3, Lamda automatically resize images = Lambda
Comment: Check this : https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html Also, EKS does not require VPC endpoints. This is not the right use case for EKS
Comment: correct i was going for B, but A looks better. https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html "When you enable endpoint private access for your cluster, Amazon EKS creates a Route 53 private hosted zone on your behalf and associates it with your cluster's VPC. This private hosted zone is managed by Amazon EKS, and it doesn't appear in your account's Route 53 resources. "
Comment: https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html#:~:text=Before,launched "Before you can launch nodes and register them into a cluster, you must create an IAM role for those nodes to use when they are launched."
Comment: By creating interface VPC endpoints, you can enable the necessary communication between the Amazon EKS control plane and the nodes in private subnets. This solution ensures that the control plane maintains endpoint private access (set to true) and endpoint public access (set to false) for security compliance.
Comment: AmazonEKSNodeRole IAM role https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html
Comment:
When Amazon EKS nodes cannot join the cluster, especially when the control plane is set to private access only, the issue typically revolves around networking and connectivity. When the EKS control plane is configured with private access only, the nodes must communicate with the control plane over private IP addresses. Creating VPC endpoints (specifically, com.amazonaws.
Comment: I think is B.
Comment: Error they have mentioned is at network level. They are not saying authorisation is failed rather noce is enable to connect to cluster aka connectivity issue. So answer it must be B
Comment: https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html "Any self-managed nodes must be deployed to subnets that have the VPC interface endpoints that you require. If you create a managed node group, the VPC interface endpoint security group must allow the CIDR for the subnets, or you must add the created node security group to the VPC interface endpoint security group."
Comment: I Think is A
Comment: B is good to go
Comment: S3/DynamoDB - VPC endpoint, other service should use interface endpoint so B is incorrect
Comment: Because of these two assertions: - Amazon EKS control plane with endpoint private access set to true and endpoint public access set to false to maintain security compliance. ( The company must also put the data plane in private subnets. The best answer is related to Networking, Private Subnets (EKS Ctr Plane is strictly private and Data Plane stick under private subnets) and not related to EKS autodeployment that sure need an IAM policy. So according to me, answer B is the best answer.
Comment: Before can launch nodes and register nodes into a EKS cluster, must create an IAM role for those nodes to use when they are launched.
Comment: A is correct: To deploy a new EKS cluster: 1. Need to have a VPC and at least 2 subnets 2. An IAM role that have permission to create and describe EKS cluster
Comment: A is good to go. B is not correct because they already setup connection to control plane.
Comment: "They already setup connection to control plane" where did you read that?
Comment: In Amazon EKS, nodes need to communicate with the EKS control plane. When the Amazon EKS control plane endpoint access is set to private, you need to create interface VPC endpoints in the VPC where your nodes are running. This allows the nodes to access the control plane privately without needing public internet access.
Comment: This should be an associate-level question. https://repost.aws/knowledge-center/eks-worker-nodes-cluster https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html
Comment: This should NOT be an associate-level question
Comment: Since the EKS control plane has public access disabled and is in private subnets, the EKS nodes in the private subnets need interface VPC endpoints to reach the control plane API. Creating these interface endpoints allows the EKS nodes to communicate with the control plane privately within the VPC to join the cluster.
Comment: Why B Private Control Plane: You've configured the Amazon EKS control plane with private endpoint access, which means the control plane is not accessible over the public internet. VPC Endpoints: When the control plane is set to private access, you need to set up VPC endpoints for the Amazon EKS service so that the nodes in your private subnets can communicate with the EKS control plane without going through the public internet. These are known as interface VPC endpoints.
Comment: Reason why, not A While security groups and IAM permissions are important considerations for networking and authentication, they alone won't resolve the issue of nodes not being able to join the cluster when the control plane is configured for private access.
Comment: Amazon Redshift is a data warehouse solution, so it is suitable for: -Supporting encryption (client-side and server-side) -Handling analytics workloads, especially during off-peak hours when the application is less active -Scaling to large amounts of data and high query volumes for analytics purposes The following options are incorrect because: A) Data APIs are not typically used with Redshift. It is more for running SQL queries and analytics. D) Redshift is not typically used for caching data. It is for analytics and data warehouse purposes. F) Redshift clusters do not create replicas in the management console. They are standalone clusters. you could create DR cluster from snapshot and restore to another region (automated or manual) but I do not think this what is meant in this option.
Comment: "Data APIs are not typically used with Redshift" -> "With the Data API, you can programmatically access data in your Amazon Redshift cluster from different AWS services such as AWS Lambda, Amazon SageMaker notebooks, AWS Cloud9, and also your on-premises applications using the AWS SDK. This allows you to build cloud-native, containerized, serverless, web-based, and event-driven applications on the AWS Cloud."
Comment: B is not correct, how it can do encryption at client side ?
Comment: Found this related to A -- but specific to Redshift Serverless - but should qualify as a Redshift use case The Data API enables you to seamlessly access data from Redshift Serverless with all types of traditional, cloud-native, and containerized serverless web service-based applications and event-driven applications. https://www.amazonaws.cn/en/blog-selection/use-the-amazon-redshift-data-api-to-interact-with-amazon-redshift-serverless/
Comment: The following are obviously incorrect: (D) Redshift is not as suitable as ElastiCache for caching. (F) A secondary replica of the cluster is not supported. The debate is between BCE & ACE or simplified, between A & C. (A) is incorrect bc there is a difference btw Amazon Redshift Data API & API Gateway. API Gateway supports containerized and serverless workloads, as well as web applications. Amazon Redshift Data API is a built in API to access Redshift data with web services–based applications, including AWS Lambda, Amazon SageMaker notebooks, and AWS Cloud9. https://aws.amazon.com/blogs/big-data/build-a-serverless-analytics-application-with-amazon-redshift-and-amazon-api-gateway/ (B) is correct. You have the following options of protecting data at rest in Amazon Redshift. Use server-side encryption OR use client-side encryption https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption.html
Comment: Redshift is OLAP(online analytical processing) so D is wrong, "when the application is not active"
Comment: *C is wrong
Comment: A, C, E are for data and Redshift is data warehouse. B is too generic of a choice D caching is not the main purpose of Redshift F replication is not main use of Redshift CE are easy Between AB, I chose A because Redshift supports data API and client-side encryption is not Redshift specific
Comment: A: source https://aws.amazon.com/blogs/big-data/using-the-amazon-redshift-data-api-to-interact-with-amazon-redshift-clusters/ B: source: https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption.html C: not sure, but you can configure scheduled queries, but the remark " and when the application is not active " , that is not relevant. D: source https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html E: Scaling globally is not supported; redshift is only a regional service. F: only read replica is supported. So not a secondary replica of the cluster.
Comment: A: https://aws.amazon.com/de/blogs/big-data/get-started-with-the-amazon-redshift-data-api/ B: https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption.html D: https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html#result-caching Not C: Redshift is a Data Warehouse; you can use that for analytics, but it is not directly related to an "application" Not E: "Petabytes of data" yes, but "tens of millions of requests per minute" is not a typical feature of Redshift Nor F: Replicas are not a Redshift feature
Comment: Technically both options A and B apply, this is from the links below: A. You can access your Amazon Redshift database using the built-in Amazon Redshift Data API. https://docs.aws.amazon.com/redshift/latest/mgmt/data-api.html#:~:text=in%20Amazon%20Redshift-,Data%20API,-.%20Using%20this%20API B. You can encrypt data client-side and upload the encrypted data to Amazon Redshift. In this case, you manage the encryption process, the encryption keys, and related tools. https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption.html#:~:text=Use-,client%2Dside,-encryption%20%E2%80%93%20You%20can
Comment: Amazon Redshift provides a Data API that you can use to painlessly access data from Amazon Redshift with all types of traditional, cloud-native, and containerized, serverless web services-based and event-driven applications. Amazon Redshift supports up to 500 concurrent queries per cluster, which may be expanded by adding more nodes to the cluster.
Comment: change to ABD To reduce query runtime and improve system performance, Amazon Redshift caches the results of certain types of queries in memory on the leader node. When a user submits a query, Amazon Redshift checks the results cache for a valid, cached copy of the query results. If a match is found in the result cache, Amazon Redshift uses the cached results and doesn't run the query. Result caching is transparent to the user.
Comment: The key use cases for Amazon Redshift that fit this scenario are: B) Redshift supports both client-side and server-side encryption to protect sensitive data. C) Redshift is well suited for running batch analytics workloads during off-peak times without affecting OLTP systems. E) Redshift can scale to massive datasets and concurrent users to support large analytics workloads.
Comment: Why E lol? It's a data warehouse! it has no need to support millions of requests, it is not mentioned anywhere (https://aws.amazon.com/redshift/features) In fact Redshift editor supports max 500 connections and workgroup support max 2000 connections at once, see it's quota page Redshift has a cache layer, D is correct
Comment: BCE, For B this is why https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption.html
Comment: Quote: "The Data API enables you to seamlessly access data from Redshift Serverless with all types of traditional, cloud-native, and containerized serverless web service-based applications and event-driven applications." at https://aws.amazon.com/blogs/big-data/use-the-amazon-redshift-data-api-to-interact-with-amazon-redshift-serverless/ (28/4/2023). Choose A. B and C are next chosen correct answers.
Comment: Typo, I want said "C and E are next chosen correct answers."
Comment: https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html
Comment: B. Supporting client-side and server-side encryption: Amazon Redshift supports both client-side and server-side encryption for improved data security. C. Building analytics workloads during specified hours and when the application is not active: Amazon Redshift is optimized for running complex analytic queries against very large datasets, making it a good choice for this use case. E. Scaling globally to support petabytes of data and tens of millions of requests per minute: Amazon Redshift is designed to handle petabytes of data, and to deliver fast query and I/O performance for virtually any size dataset.
Comment: CEF for me
Comment: In the context of the given scenario, where the company wants low latency and consistent performance for their API during peak usage times, it would be more suitable to use provisioned concurrency. By allocating a specific number of concurrent executions, the company can ensure that there are enough function instances available to handle the expected load and minimize the impact of cold starts. This will result in lower latency and improved performance for the API.
Comment: Provisioned - minimizing cold starts and providing low latency.
Comment: https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned Consistency decreases if you exceed your provisioned instance. Lets say you have 1000 (default) provisioned instances and the load is 1500. The new 500 will have to wait until the first 1000 concurrent calls finish. This is solved by increasing the provisioned concurrency to 1500.
Comment: So I have my doubts here. The question also states ;"The company needs to provide a compute host for the API." Imho this implies to have some sort of physical host which has to be provided by the customer. Translating this further to aws this would mean an EC2 instance. And then when I would go for ECS in stead of EKS. Please share your opinion.
Comment: Exactly, inicially I was thinking on B but if company must provide a host I would say that only option A is feasible
Comment: Sorry I understand bad the text, coorect answer is B, as for my understanding now the host is the device that the costumer needs to connect with API Gateway, bellow explains well the logic https://aws.amazon.com/api-gateway/
Comment: This option provides the least operational overhead: API Gateway handles the API requests and integration with Lambda Lambda automatically scales compute without managing servers Provisioned concurrency ensures consistent low latency by keeping functions initialized No need to manage containers or orchestration platforms as with ECS/EKS
Comment: The company requires the API to respond consistently with low latency to ensure customer satisfaction especially during high peak periods, there is no mention of cost efficient. Hence provisioned concurrency is the best option. Provisioned concurrency is the number of pre-initialized execution environments you want to allocate to your function. These execution environments are prepared to respond immediately to incoming function requests. Configuring provisioned concurrency incurs charges to your AWS account. https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#:~:text=for%20a%20function.-,Provisioned%20concurrency,-%E2%80%93%20Provisioned%20concurrency%20is
Comment: AWS Lambda provides a highly scalable and distributed infrastructure that automatically manages the underlying compute resources. It automatically scales your API based on the incoming request load, allowing it to respond consistently with low latency, even during peak times. AWS Lambda takes care of infrastructure provisioning, scaling, and resource management, allowing you to focus on writing the code for your API logic.
Comment: send logs to Amazon S3 from AWS Systems Manager Session Manager. Here are the steps to do so: Enable S3 Logging: Open the AWS Systems Manager console. In the navigation pane, choose Session Manager. Choose the Preferences tab, and then choose Edit. Select the check box next to Enable under S3 logging. Create an S3 Bucket: To store the Session Manager logs, create an S3 bucket to hold the audit logs from the Session Manager interactive shell usage. Configure IAM Role: AWS Systems Manager Agent (SSM Agent) uses the same AWS Identity and Access Management (IAM) role to activate itself and upload logs to Amazon S3. You can use either an IAM instance profile that's attached to an Amazon Elastic Compute Cloud (Amazon EC2) instance or the IAM role that's configured for the Default Host Management Configuration.
Comment: A, You can choose to store session log data in a specified Amazon Simple Storage Service (Amazon S3) bucket for debugging and troubleshooting purposes. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html#session-manager-logging-s3
Comment: Most efficient is A because it is a direct option in SM logging. B can work but is more operational overhead as you end up using CloudWatch (not sure how but making assumption based on language of option) C is definitely too much work D Way too many moving parts
Comment: You can choose to store session log data in a specified Amazon Simple Storage Service (Amazon S3) bucket for debugging and troubleshooting purposes.
Comment: You can config the log archived to S3 in the Session Manager - > preference tab. Another option is CloudWatch log. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html#session-manager-logging-s3
Comment: °Simplicity - Enabling S3 logging requires just a simple configuration in the Systems Manager console to specify the destination S3 bucket. No other services need to be configured. °Direct integration - Systems Manager has native support to send session logs to S3 through this feature. No need for intermediary services. °Automated flow - Once S3 logging is enabled, the session logs automatically flow to the S3 bucket without manual intervention. °Easy management - The S3 bucket can be managed independently for log storage and archival purposes without impacting Systems Manager. °Cost-effectiveness - No charges for intermediate CloudWatch or Kinesis services. Just basic S3 storage costs. °Minimal overhead - No ongoing management of complex pipeline of services. Direct logs to S3 minimizes overhead.
Comment: With the MOST operational efficiency then option A is best. Otherwise B is also an option with a little bit more ops than option A. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html
Comment: Answer A. https://aws-labs.net/winlab5-manageinfra/sessmgrlog.html
Comment: GPT argued for D. B could be an option, by installing a logging package on alle managed systems/ECs etc. https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html However, as it mentions the "Session manager logs" I would tend towards A.
Comment: It should be "A". https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html
Comment: It have menu to Enable S3 Logging. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html#session-manager-logging-s3
Comment: BBBBBBBBB
Comment: "Install the CloudWatch agent" where?
Comment: The option 'A' says "Enable S3 logging in the Systems Manager console." This means that you will enable the logs !! FOR !! S3 events and its is not what the question asks. My vote is for Option B, based on this article: https://docs.aws.amazon.com/AmazonS3/latest/userguide/logging-with-S3.html
Comment: To log session data using Amazon S3 (console) Open the AWS Systems Manager console at https://console.aws.amazon.com/systems-manager/. In the navigation pane, choose Session Manager. Choose the Preferences tab, and then choose Edit. Select the check box next to Enable under S3 logging.
Comment: But where do you want to install the Amazon CloudWatch agent in case of B?
Comment: DDDDDD
Comment: Option D is definetely not right, Its optiom B
Comment: Chat GPT says option A is incorrect cos it requires enabling S3 logging in the system manager console only logs information about the systems manager service not the session logs Says correct answer is B
Comment: Question may not be very clear. A should be the answer. Below link is the documetation: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html#session-manager-logging-s3
Comment: option A does not involve CloudWatch, while option D does. Therefore, in terms of operational overhead, option A would generally have less complexity and operational overhead compared to option D. Option A simply enables S3 logging in the Systems Manager console, allowing you to directly send session logs to an S3 bucket. This approach is straightforward and requires minimal configuration. On the other hand, option D involves installing and configuring the Amazon CloudWatch agent, creating a CloudWatch log group, setting up a CloudWatch Logs subscription, and configuring an Amazon Kinesis Data Firehose delivery stream to store logs in an S3 bucket. This requires additional setup and management compared to option A. So, if minimizing operational overhead is a priority, option A would be a simpler and more straightforward choice.
Comment: Enabling storage autoscaling allows RDS to automatically adjust the storage capacity based on the application's needs. When the storage usage exceeds a predefined threshold, RDS will automatically increase the allocated storage without requiring manual intervention or causing downtime. This ensures that the RDS database has sufficient disk space to handle the increasing storage requirements.
Comment: Autoscaling.... without downtime...
Comment: Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon RDS for SQL Server and Amazon RDS for Oracle support RDS Storage Auto Scaling. RDS Storage Auto Scaling automatically scales storage capacity in response to growing database workloads, with zero downtime.
Comment: This question is so obvious
Comment: RDS Storage Auto Scaling continuously monitors actual storage consumption, and scales capacity up automatically when actual utilization approaches provisioned storage capacity. Auto Scaling works with new and existing database instances. You can enable Auto Scaling with just a few clicks in the AWS Management Console. There is no additional cost for RDS Storage Auto Scaling. You pay only for the RDS resources needed to run your applications. https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/#:~:text=of%20the%20rest.-,RDS%20Storage%20Auto%20Scaling,-continuously%20monitors%20actual
Comment: Quote "Amazon RDS now supports Storage Auto Scaling" and "... with zero downtime." (Jun 20th 2019) at https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/
Comment: Hello moderator, please help me delete this discussion, I already add content before this comment.
Comment: See “Amazon RDS now supports Storage Auto Scaling. Posted On: Jun 20, 2019. Starting today, Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon RDS for SQL Server and Amazon RDS for Oracle support RDS Storage Auto Scaling. RDS Storage Auto Scaling automatically scales storage capacity in response to growing database workloads, with zero downtime.” at https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/
Comment: A is the best answer. B will not work for increasing disk space, it only improve the IO performance. C will not work because it will cause downtime. D is too complicated and need much operational effort.
Comment: https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/
Comment: The key word is No Down time. A would be bewt option
Comment: AWS Service Catalog allows you to create and manage catalogs of IT services that can be deployed within your organization. With Service Catalog, you can define a standardized set of products (solutions and tools in this case) that customers can self-service provision. By creating Service Catalog products, you can control and enforce the deployment of approved and validated solutions and tools.
Comment: "within your organization" => not for customers
Comment: Some key advantages of using Service Catalog: Centralized management - Products can be maintained in a single catalog for easy discovery and governance. Self-service access - Customers can deploy the solutions on their own without manual intervention. Standardization - Products provide pre-defined templates for consistent deployment. Access control - Granular permissions can be applied to restrict product visibility and access. Reporting - Service Catalog provides detailed analytics on product usage and deployments.
Comment: CloudFormation: a code as infrastructure service Systems Manager: management solution for resources Config: assess, audit and evaluate configurations Other options does not fit this scenario.
Comment: AWS Service Catalog lets you centrally manage your cloud resources to achieve governance at scale of your infrastructure as code (IaC) templates, written in CloudFormation or Terraform. With AWS Service Catalog, you can meet your compliance requirements while making sure your customers can quickly deploy the cloud resources they need. https://aws.amazon.com/servicecatalog/#:~:text=How%20it%20works-,AWS%20Service%20Catalog,-lets%20you%20centrally
Comment: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html
Comment: B for me. Provisioned if we know how much traffic will come, but its unpredictable, so we have to go for on-demand
Comment: Spot On
Comment: Configure DynamoDB in on-demand mode by using the DynamoDB Standard table class. This option allows DynamoDB to automatically adjust to varying traffic patterns, which is ideal for unpredictable workloads. The Standard table class is suitable for applications with moderate to high read and write throughput, and on-demand mode ensures that you are billed based on the actual usage, providing cost efficiency for variable traffic patterns.
Comment: Key word : On demand. So I think B.
Comment: On demand https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html "With on-demand capacity mode, DynamoDB charges you for the data reads and writes your application performs on your tables. You do not need to specify how much read and write throughput you expect your application to perform because DynamoDB instantly accommodates your workloads as they ramp up or down."
Comment: Not A because of "unpredictable" traffic Not C and D because we are expecting "moderate to high" traffic
Comment: Leaning towards B, it's hard to predict the capacity for A, and autoscaling doesn't respond fast
Comment: it's A. remember that : he company expects that the application read and write throughput to the database will be moderate to high provisioned throughput is cheaper than ondemand capacity right ?
Comment: but "unpredictable" which usually hints to on-demand
Comment: Data storage: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.tableclasses.html
Comment: Actually, this link confirmed "B" for me...
Comment: On-demand mode is great for unpredictable traffic
Comment: I choose B I think the items stored in the table in this question has large size. So each read/write, a big chunk of data pass through. A capacity unit is used to describe data throughput. provision to the high capacity units will be a waste because unpredicted traffic pattern.
Comment: Unpredictable= on demand
Comment: The key factors are: With On-Demand mode, you only pay for what you use instead of over-provisioning capacity. This avoids idle capacity costs. DynamoDB Standard provides the fastest performance needed for moderate-high traffic apps vs Standard-IA which is for less frequent access. Auto scaling with provisioned capacity can also work but requires more administrative effort to tune the scaling thresholds.
Comment: Support for B from AWS: On-demand mode is a good option if any of the following are true: -You create new tables with unknown workloads. -You have unpredictable application traffic. -You prefer the ease of paying for only what you use. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
Comment: Technically both options A and B will work. But this statement 'traffic will be unpredictable' rules out option A, because 'provisioned mode' was made for scenarios where traffic is predictable. So I will stick with B, because 'on-demand mode' is made for unpredictable traffic and instantly accommodates workloads as they ramp up or down.
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html
Comment: Not B for sure, "The company needs to scale in response to application traffic." Between A and C, I would choose C. Because it's a new application, and the traffic will be from moderate to high. So by choosing C, it's both cost-effecitve and scalable
Comment: "With provisioned capacity mode, you specify the number of reads and writes per second that you expect your application to require, and you are billed based on that. Furthermore if you can forecast your capacity requirements you can also reserve a portion of DynamoDB provisioned capacity and optimize your costs even further. With provisioned capacity you can also use auto scaling to automatically adjust your table's capacity based on the specified utilization rate to ensure application performance, and also to potentially reduce costs. To configure auto scaling in DynamoDB, set the minimum and maximum levels of read and write capacity in addition to the target utilization percentage." https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html
Comment: IAM Roles: IAM roles provide a secure way to grant permissions to entities within AWS. By creating an IAM role in each business account named BU_ROLE with the necessary permissions to access the DynamoDB table, the access can be controlled at the IAM role level. Cross-Account Access: By configuring a trust policy in the BU_ROLE that trusts a specific role in the inventory application account (APP_ROLE), you establish a trusted relationship between the two accounts. Least Privilege: By creating a specific IAM role (BU_ROLE) in each business account and granting it access only to the required DynamoDB table, you can ensure that each team's table is accessed with the least privilege principle. Security Token Service (STS): The use of STS AssumeRole API operation in the inventory application account allows the application to assume the cross-account role (BU_ROLE) in each business account.
Comment: Well broken down..thank you :)
Comment: C because they have taken effort to explain it in details.. lol
Comment: Keyword: IAM ROLES
Comment: C is the most secure option to meet the requirements. Using cross-account IAM roles and role chaining allows the inventory application to securely access resources in other accounts. The roles provide temporary credentials and can be permissions controlled.
Comment: Looks complex, but IAM role seems more probable, I go with C.
Comment: Why not A?
Comment: A is wrong because it is incomplete. Just integrating with secrets manager doesn't give any access to DynamoDB.
Comment: It's complex, but looks C.
Comment: i'll go with C .. coming from two minds
Comment: a or c. C looks like a more secure
Comment: CCCCCCCCCCC
Comment: B and C are the correct options. Using the Kubernetes Metrics Server (B) enables horizontal pod autoscaling to dynamically scale pods based on CPU/memory usage. This allows scaling at the application tier level. The Kubernetes Cluster Autoscaler (C) automatically adjusts the number of nodes in the EKS cluster in response to pod resource requirements and events. This allows scaling at the infrastructure level.
Comment: K8S Metrics Server and Autoscaler => B and C
Comment: This is pretty straight forward. Use the Kubernetes Metrics Server to activate horizontal pod autoscaling. Use the Kubernetes Cluster Autoscaler to manage the number of nodes in the cluster.
Comment: Kubernetes Metrics Server https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html AWS Autoscaler https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html and https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md
Comment: By combining the Kubernetes Cluster Autoscaler (option C) to manage the number of nodes in the cluster and enabling horizontal pod autoscaling (option B) with the Kubernetes Metrics Server, you can achieve automatic scaling of your EKS cluster and container applications based on workload demand. This approach minimizes operational overhead as it leverages built-in Kubernetes functionality and automation mechanisms.
Comment: b and c is right
Comment: just passed yesterday 30-05-23, around 75% of the exam came from here, some with light changes.
Comment: Great work made it to the last question. Goodluck to you all
Comment: Thanks. Do you think the questions after 500 after relevant, they seem to be above associate level (harder)
Comment: I am jealous that 10 months ago there were only 523 questions :(
Comment: right...how to go through 840 questions :(
Comment: Currently 904 :')
Comment: moderators answer is wrong for many questions.which one should we consider:(
Comment: good luck to you as well.
Comment: Is there anyone who has recently passed the exam who can tell me approximately how many of the original questions are in the actual exam?
Comment: let me know for most of questions that system answer are correct or comment answer are correct?
Comment: Comment answer
Comment: https://docs.amazonaws.cn/en_us/athena/latest/ug/connect-to-a-data-source.html
Comment: key word is most operational effective => D requires no coding
Comment: I'll go with D as ABC looks too much work or irrelevant. Although not sure how AFQ actually achieves the read without impacting performance.
Comment: Not A - Pipe Resolvers require coding, would not consider that 'operationally efficient' Not B - CloudFront caches web content at the edge, not DynamoDB query results for apps Not C - Neither API Gateway or Lambda have anything to do with DynamoDB performance D - Can do exactly that
Comment: I am not an expert but I used Bing+Gemini+Chatgbt=AAA
Comment: multiple database tables = AppSync pipeline resolvers
Comment: For an operationally efficient solution that minimizes impact on baseline performance in a microservice-based serverless web application retrieving data from multiple DynamoDB tables, Amazon CloudFront with Lambda@Edge functions (Option B) is often the most suitable choice
Comment: CloudFront to retrieve data from DynamoDB tables?
Comment: D is correct. There is contruction of how to retrive data from DynamoDB with Anthena https://docs.aws.amazon.com/athena/latest/ug/connect-to-a-data-source.html
Comment: The Answer is A. Some use case for AWS AppSync is Unified data access. Consolidate data from multiple databases, APIs, and microservices in a single network call, from a single endpoint, abstracting backend complexity. https://aws.amazon.com/pm/appsync/?trk=e37f908f-322e-4ebc-9def-9eafa78141b8≻_channel=ps&ef_id=Cj0KCQjwmvSoBhDOARIsAK6aV7jtg2I6jyXBH6_uUOKRrRoLmXQxaGbwYBP0aO1-RmauWW55DuXSGTMaAnT9EALw_wcB:G:s&s_kwcid=AL!4422!3!647301987556!e!!g!!aws%20appsync!19613610159!148358960849
Comment: B - seems more operationally efficient A: example to make use of GraphQL with multi DynamoDB tables https://www.youtube.com/watch?v=HSDKN43Vx7U but it seems not the most operationally efficient to set it up D: it can be useful when needs to join multi DynamoDB tables But also "querying DynamoDB using Athena can be slower and more expensive than querying directly using DynamoDB" refer to https://medium.com/@saswat.sahoo.1988/combine-the-simplicity-of-sql-with-the-power-of-nosql-pt-2-cff1c524297e
Comment: A is correct. https://aws.amazon.com/blogs/mobile/appsync-pipeline-resolvers-2/
Comment: https://aws.amazon.com/pm/appsync/?trk=66d9071f-eec2-471d-9fc0-c374dbda114d≻_channel=ps&ef_id=CjwKCAjww7KmBhAyEiwA5-PUSi9OTSRu78WOh7NuprwbbfjyhVXWI4tBlPquEqRlXGn-HLFh5qOqfRoCOmMQAvD_BwE:G:s&s_kwcid=AL!4422!3!646025317347!e!!g!!aws%20appsync!19610918335!148058250160
Comment: I like D) the most. D. Amazon Athena Federated Query with a DynamoDB connector. I don't like A) since this is not a GraphQL query. I don't like B). Since Query multiple tables in DynamoDB from Lambda may not be efficient.
Comment: https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html When troubleshooting you will want to query specific things in the log and Athena provides query language for that. Quick Sight is data analytics and visualisation tool. You can use it to aggregate data and maybe make a dashboard for number of errors by type etc but that doesn't help you troubleshoot anything. C is correct
Comment: "Search CloudTrail logs with Amazon QuickSight", that doesn't work. QuickSight can visualize Athena query results, so "search CloudTrail logs with Amazon Athena, then create a dashboard with Amazon QuickSight" would make sense. But QuickSight without Athena won't work.
Comment: Athena is for searching
Comment: The question asks specifically to "analyze and troubleshoot". While Athena is easy to get the data, you then just have a list of logs. Not very useful to troubleshoot...
Comment: How will pretty pictures in QuickSight help with troubleshooting?
Comment: But without Athena, there is nothing you can visualize in QuickSight.
Comment: Quick Sight is an analytics tool. Sounds like a LEAST effort option
Comment: Athena allows you to run SQL queries on data in Amazon S3, including CloudTrail logs. It is the easiest way to query the logs and identify specific errors without needing to write any custom code or scripts. With Athena, you can write simple SQL queries to filter the CloudTrail logs for the "AccessDenied" and "UnauthorizedOperation" error codes. This will return the relevant log entries that you can then analyze.
Comment: C for me. Using Athena with CloudTrail logs is a powerful way to enhance your analysis of AWS service activity. For example, you can use queries to identify trends and further isolate activity by attributes, such as source IP address or user. https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#:~:text=CloudTrail%20Lake%20documentation.-,Using%20Athena,-with%20CloudTrail%20logs
Comment: IAM and CloudTrail https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#stscloudtrailexample-assumerole . Query CloudTrail logs by Athena https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#tips-for-querying-cloudtrail-logs#tips-for-querying-cloudtrail-logs
Comment: Choose C, not D, because need “analyze and troubleshoot”, not just see on dashboard (in D).
Comment: Amazon Athena is an interactive query service provided by AWS that enables you to analyze data , is a little bit more suitable integrated with cloud trail that permit to verify WHO accessed the service.
Comment: Dashboard isnt requires. Also refer to this https://repost.aws/knowledge-center/troubleshoot-iam-permission-errors
Comment: I am struggling for the C and D for a long time, and ask the chatGPT. The chatGPT says D is better, since Athena requires more expertise on SQL.
Comment: Both C and D are feasible. I vote for D: Amazon QuickSight supports logging the following actions as events in CloudTrail log files: - Whether the request was made with root or AWS Identity and Access Management user credentials - Whether the request was made with temporary security credentials for an IAM role or federated user - Whether the request was made by another AWS service https://docs.aws.amazon.com/quicksight/latest/user/logging-using-cloudtrail.html
Comment: The Answer will be C: Need to use Athena to query keywords and sort out the error logs. D: No need to use Amazon QuickSight to create the dashboard.
Comment: "Using Athena with CloudTrail logs is a powerful way to enhance your analysis of AWS service activity." https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
Comment: Analyse and TROUBLESHOOT, look like Athena
Comment: https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
Comment: It specifies analyze, not query logs. Which is why option D is the best one as it provides dashboards to analyze the logs.
Comment: Keyword 12 months, API Support https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
Comment: Programmatically + LEAST overhead = API
Comment: access to its usage cost programmatically = AWS Cost Explorer API
Comment: A: correct 1. programatically = API 2. In the next 12 months = cost explorer
Comment: Access usage cost-related data by using the AWS Cost Explorer API with pagination
Comment: don't repeat the answer, it is useless... explain , okay? i have seen your replies many time just to copy the options.. it makes no sense...
Comment: AWS Cost Explorer API with paginated request: https://docs.aws.amazon.com/cost-management/latest/userguide/ce-api-best-practices.html#ce-api-best-practices-optimize-costs
Comment: From AWS Documentation*: "You can view your costs and usage using the Cost Explorer user interface free of charge. You can also access your data programmatically using the Cost Explorer API. Each paginated API request incurs a charge of $0.01. You can't disable Cost Explorer after you enable it." * Source: https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-cost-explorer/interfaces/costexplorerpaginationconfiguration.html
Comment: Answer is: A says dashboard = Cost Explorer, therefor C & D are eliminated. also says programmatically, means non manual intervention therefor API.
Comment: least operational overhead = API access
Comment: least operational overhead = API access
Comment: D is the correct answer. It is talking about the write database. Not reader. Amazon RDS proxy allows you to automatically route write request to the healthy writer, minimizing downtime.
Comment: One of the benefits of Amazon RDS Proxy is that it can improve application recovery time after database failovers. While RDS Proxy supports both MySQL as well as PostgreSQL engines, in this post, we will use a MySQL test workload to demonstrate how RDS Proxy reduces client recovery time after failover by up to 79% for Amazon Aurora MySQL and by up to 32% for Amazon RDS for MySQL. https://aws.amazon.com/blogs/database/improving-application-availability-with-amazon-rds-proxy/ https://aws.amazon.com/rds/proxy/faqs/
Comment: AWS EXAM is also an AWS promotion... RDS Proxy really does not reduce recovery time if you don't have alternative RDS instance. You will see if you understand what proxy is. But this is exam (= promotion) of AWS, D could be an answer, because some AWS document says so.
Comment: "RDS Proxy reduces client recovery time after failover by up to 79% for Amazon Aurora MySQL " https://aws.amazon.com/de/blogs/database/improving-application-availability-with-amazon-rds-proxy/
Comment: RDS Proxy is used for DB timeout not downtime. How to reduce downtime with RDS Proxy? There is no change downtime if we use RDS Proxy.
Comment: "How to reduce downtime with RDS Proxy", by eliminating the need for the application to retrieve the new DNS record after the old one times out.
Comment: I would never have thought about DNS records in this question. Nice catch!
Comment: "RDS Proxy reduces client recovery time after failover by up to 79% for Amazon Aurora MySQL " https://aws.amazon.com/de/blogs/database/improving-application-availability-with-amazon-rds-proxy/
Comment: they are using Aurora, RDS proxy dont work here Answer B
Comment: Wrong: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: "RDS Proxy reduces client recovery time after failover by up to 79% for Amazon Aurora MySQL " https://aws.amazon.com/de/blogs/database/improving-application-availability-with-amazon-rds-proxy/
Comment: D. Set up an Amazon RDS proxy for the database. Update the application to use the proxy endpoint.
Comment: point is Aurora Multi-Master Set up a secondary Aurora PostgreSQL cluster in the *same* AWS Region
Comment: I mean correct is B
Comment: Availability is the main requirement here. Even if RDS proxy is used, it will still find the writer instance unavailable during the scaling exercise. Best option is to create an Amazon ElastiCache for Memcached cluster to handle the load during the scaling operation.
Comment: that will only account for the read operation part of it, we are concerned with the write operations here
Comment: "RDS Proxy reduces client recovery time after failover by up to 79% for Amazon Aurora MySQL " https://aws.amazon.com/de/blogs/database/improving-application-availability-with-amazon-rds-proxy/
Comment: Failover is faster with RDS proxy
Comment: Set up an Amazon RDS proxy for the database. Update the application to use the proxy endpoint. D is the answer
Comment: Auto Scaling groups can span Availability Zones, but not AWS regions. Hence the best option is to deploy the web tier and the application tier to a second Region. Use an Amazon Aurora global database to deploy the database in the primary Region and the second Region. Use Amazon Route 53 health checks with a failover routing policy to the second Region. Promote the secondary to primary as needed.
Comment: A: Not possible for autoscaling across regions BC: Using PostgreSQL, not sure why? D: MOST fault tolerant != MOST scalable. This gives least downtime.
Comment: EC2 Auto Scaling groups are regional constructs. They can span Availability Zones, but not AWS regions
Comment: 527: D is correct: - B & C is not correct because it mentions Aurora PostgreSQL which is not mentioned in the question - A is not correct because Auto scaling group can not span regions
Comment: Simple as that.
Comment: Using an Aurora global database that spans both the primary and secondary regions provides automatic replication and failover capabilities for the database tier. Deploying the web and application tiers to a second region provides fault tolerance for those components. Using Route53 health checks and failover routing will route traffic to the secondary region if the primary region becomes unavailable. This provides fault tolerance across all tiers of the architecture while minimizing downtime. Promoting the secondary database to primary ensures the second region can continue operating if needed. A is close, but doesn't provide an automatic database failover capability. B and C provide database replication, but not automatic failover. So D is the most comprehensive and fault tolerant architecture.
Comment: Answer D
Comment: D seems fitting: Global Databbase and deploying it in the new region
Comment: B is correct!
Comment: Replicated db doesnt mean they will act as a single db once the transfer is completed. Global db is the correct approach
Comment: "D" is the answer: because Aws Aurora Global Database allows you to read and write from any region in the global cluster. This enables you to distribute read and write workloads globally, improving performance and reducing latency. Data is replicated synchronously across regions, ensuring strong consistency.
Comment: A is the only answer remain using ELB, both Web/App/DB has been taking care with replicating in 2nd region, lastly route 53 for failover over multiple regions
Comment: i will revoke my answer to standby web in 2nd region, instead of trigger to scale out
Comment: also Asg cant span beyond a region
Comment: B&C are discarted. The answer is between A and D. I would go with D because it explicitley created this web / app tier in second region, instead A just autoscales into a secondary region, rather then always having resources in this second region.
Comment: Obviously we choose AWS Transfer Family over hosting the FTP server ourselves on an EC2 instance. And "process incoming data files as soon as possible" -> trigger Lambda when files arrive. Lambda functions can run up to 15 minutes, it takes "3-8 minutes" per file -> works. AWS Batch just schedules jobs, but these still need to run somewhere (Lambda, Fargate, EC2).
Comment: well if you opt for unmanaged compute option in AWS Batch in that case you dont have to worry about the compute, AWS batch automatically provisions it for you
Comment: FTP => AWS Transfer Family, => C or D, but in C is used EBS not S3 which needs EC2 and in general is more complex => very clear D.
Comment: The key points: Use AWS Transfer Family for the FTP server to receive files directly into S3. This avoids managing FTP servers. Process each file as soon as it arrives using Lambda triggered by S3 events. Lambda provides fast processing time per file. Lambda can also delete files after processing succeeds. Options A, B, C involve more operational overhead of managing FTP servers and batch jobs. Processing latency would be higher waiting for batch windows. Storing files in Glacier (Option A) adds latency for retrieving files.
Comment: Processing for each file needs to take 3-8 minutes clearly indicates Lambda functions.
Comment: Process incoming data files with minimal changes to the FTP clients that send the files = AWS Transfer Family. Process incoming data files as soon as possible = S3 event notification. Processing for each file needs to take 3-8 minutes = AWS Lambda function. Delete file after processing = AWS Lambda function.
Comment: Most likely D.
Comment: "D" Since each file takes 3-8 minutes to process the lambda function can process the data file whitout a problem.
Comment: You cannot setup AWS Transfer Family to save files into EBS.
Comment: https://aws.amazon.com/aws-transfer-family/
Comment: D. Because 1. process immediate when file transfer to S3 not wait for process several file in one time. 2. takes 3-8 can use Lamda. C. Wrong because AWS Batch is use for run large-scale or large amount of data in one time.
Comment: To meet the requirements of processing incoming data files as soon as possible with minimal changes to the FTP clients, and deleting the files after successful processing, the most operationally efficient solution would be: D. Use AWS Transfer Family to create an FTP server to store incoming files in Amazon S3 Standard. Create an AWS Lambda function to process the files and delete them after processing. Use an S3 event notification to invoke the Lambda function when the files arrive.
Comment: It should be D as lambda is more operationally viable solution given the fact each processing takes 3-8 minutes that lambda can handle
Comment: Answer has to be between C or D. Because Transfer Family is obvious do to FTP. Now i would go with C because it uses AWS Batch, which makes more sense for Batch processing rather then AWS Lambda.
Comment: Why? "Process incoming data files as soon as possible", by triggering the Lambda function when files arrive. Batch is for scheduled jobs.
Comment: Also Batch just triggers jobs, they still need to run somewhere (like in Lambda).
Comment: I am between C and D. My reason is: "The company wants the AWS solution to process incoming data files as soon as possible with minimal changes to the FTP clients that send the files."
Comment: B is the answer Why not C - Option C suggests migrating the data to Amazon S3 and using Amazon Macie for data security and protection. While Amazon Macie provides advanced security features for data in S3, it may not be directly applicable or optimized for databases, especially for transactional and sensitive data. Amazon RDS provides a more suitable environment for managing databases.
Comment: A: Operational overhead of EC2 and whatever DB is running on it C: Macie is not for data security, it's for identifying PII and sensitive data D: CloudWatch is for cloud events and does not secure databases B: RDS is managed so least operational overhead. Encryption at rest means security
Comment: Migrate the databases to Amazon RDS Configure encryption at rest.
Comment: down voted.
Comment: Reduce Ops = Migrate the databases to Amazon RDS Configure encryption at rest
Comment: B for sure. First the correct is Amazon RDS, then encryption at rest makes the database secure.
Comment: B. Migrate the databases to Amazon RDS Configure encryption at rest. Looks like best option
Comment: The key considerations are: The application uses TCP and UDP for multiplayer gaming, so Network Load Balancers (NLBs) are appropriate. AWS Global Accelerator can be added in front of the NLBs to improve performance and reduce latency by intelligently routing traffic across AWS Regions and Availability Zones. Global Accelerator provides static anycast IP addresses that act as a fixed entry point to application endpoints in the optimal AWS location. This improves availability and reduces latency. The Global Accelerator endpoint can be configured with the correct NLB listener ports for TCP and UDP.
Comment: A: CloudFront is for caching. Not required B: ALB is for HTTP layer, won't help with TCP UDP issues D: API Gateway, API Caching total rubbish, ignore this option C: Is correct as Global Accelerator uses unicast for reducing latency globbally.
Comment: TCP ,UDP, Gaming = global accelerator and Network Load Balancer
Comment: only b and c handle TCP/UDP, and C comes with accelerator to enhance performance
Comment: Does alb handle udp? Can u share a source?
Comment: UDP and TCP is AWS Global accelarator as it works in the Transportation layer. Now this with NLB is perfect.
Comment: C is helping to reduce latency for end clients
Comment: A function URL is a dedicated HTTP(S) endpoint for your Lambda function. When you create a function URL, Lambda automatically generates a unique URL endpoint for you.
Comment: Keyword "Lambda function" and "webhook". See https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-saas-furls.html#create-stripe-cfn-stack
Comment: AWS Lambda can provide a URL to call using Function URLs. This is a relatively new feature in AWS Lambda that allows you to create HTTPS endpoints for your Lambda functions, making it easy to invoke the function directly over the web. Key Features of Lambda Function URLs: Direct Access: Provides a simple and direct way to call a Lambda function via an HTTP(S) request. Easy Configuration: You can create a function URL for a Lambda function using the AWS Management Console, AWS CLI, or AWS SDKs. Managed Service: AWS manages the infrastructure for you, handling scaling, patching, and maintenance. Security: You can configure authentication and authorization using AWS IAM or AWS Lambda function URL settings.
Comment: Apart from simplest and most operational, I think A is the only option that will work! BCD cannot even be implemented in real world imho. Happy to be corrected
Comment: B is the answerThe best solution to make the Lambda function available for the third party to call with the MOST operational efficiency is to deploy an Application Load Balancer (ALB) in front of the Lambda function and provide the ALB URL to the third party for the webhook. This solution is the most efficient because it allows the third party to call the Lambda function without having to worry about managing the Lambda function's availability or scaling. The ALB will automatically distribute traffic across multiple Lambda functions, if necessary, and will also provide redundancy in case of a failure.
Comment: I believe you are correct. Lambda functions as targets - implementing ALBs https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html
Comment: The key points: A Lambda function needs to be invoked by a third party via a webhook. Using a function URL provides a direct invoke endpoint for the Lambda function. This is simple and efficient. Options B, C, and D insert unnecessary components like ALB, SNS, SQS between the webhook and the Lambda function. These add complexity without benefit. A function URL can be generated and provided to the third party quickly without additional infrastructure.
Comment: key word: Lambda function URLs
Comment: https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html
Comment: It's A
Comment: A would seem like the correct one but not sure.
Comment: Step A involves registering the required domain in a registrar and creating a wildcard custom domain name in a Route 53 hosted zone. This allows you to map individual and secure URLs for all customers to your API Gateway endpoints. Step D is to request a wildcard certificate from AWS Certificate Manager (ACM) that matches the custom domain name you created in Step A. This wildcard certificate will cover all subdomains and ensure secure HTTPS communication. Step F is to create a custom domain name in API Gateway for your REST API. This allows you to associate the custom domain name with your API Gateway endpoints and import the certificate from ACM for secure communication.
Comment: The key points: Using a wildcard domain and certificate avoids managing individual domains/certs per customer. This is more efficient. The domain, hosted zone, and certificate should all be in the same region as the API Gateway REST API for simplicity. Creating multiple API endpoints per customer (Option E) adds complexity and is not required. Option B and C add unnecessary complexity by separating domains, certificates, and hosted zones.
Comment: ADF looks right but not sure why C is wrong: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html#routing-to-api-gateway-config
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html
Comment: ADF - makes sense
Comment: It's ADF
Comment: For me AFD
Comment: ADF - One to create the custom domain in Route 53 (Amazon DNS) Second to request wildcard certificate from ADM Thirds to import the certificate from ACM.
Comment: is ADF
Comment: B and D are discarted as Macie is to identify PII. Now that we have between A and C. SNS is more suitable for this option as a pub/sub service, we subscribe the security team and then they will receive the notifications.
Comment: BD: Wrong products AC: Uses Macie which is the right product but C uses SQS to notify security team which is an incomplete solution (what's listening to SQS?)
Comment: Detect PII -> Macie, A or C Notify security team -> SNS, A or B
Comment: C is SQS, not SNS
Comment: SQS mentioned in C.
Comment: Amazon SQS is typically used for decoupling and managing messages between distributed application components. It's not typically used for sending notifications directly to humans. On my opinion C isn't a best practice
Comment: Those who say C , please read carefully (I made the same mistake lol). Teams can't be notified with SQS hence A.
Comment: there are different type of sensitive data: https://docs.aws.amazon.com/macie/latest/user/findings-types.html. if the question only focus on PII, then C is the answer. however, in reality, you will use A, because you will not want bank card, credential...etc all sensitive data , not only PII
Comment: Automatically detect PII in S3 buckets = Amazon Macie Notify security team = Amazon SNS Trigger notification based on SensitiveData event type from Macie findings = EventBridge
Comment: There are different types of Sensitive Data. Here we are only referring to PII. Hence SensitiveData:S3Object/Personal. to use SNS, the security team must subscribe. SQS sends the information as designed
Comment: SensitiveData:S3Object/Personal
Comment: Sensitive = MACIE, and SNS to sent notification to the Security Team
Comment: C. Because the question mentioned PII only, there are other Sensitive Data aside from PII. reference: https://docs.aws.amazon.com/macie/latest/user/findings-publish-event-schemas.html look for Event example for a sensitive data finding
Comment: But Amazon SQS is typically used for decoupling and managing messages between distributed application components. It's not typically used for sending notifications directly to humans!
Comment: AAAAAAA
Comment: C https://docs.aws.amazon.com/macie/latest/user/findings-types.html and notice the ensitiveData:S3Object/Personal The object contains personally identifiable information (such as mailing addresses or driver's license identification numbers), personal health information (such as health insurance or medical identification numbers), or a combination of the two.
Comment: But Amazon SQS is typically used for decoupling and managing messages between distributed application components. It's not typically used for sending notifications directly to humans!
Comment: I vote for A, Sensitive = MACIE, and SNS to prevent Security Team
Comment: B is the correct solution to meet the requirement of encrypting secrets in the etcd store for an Amazon EKS cluster. The key points: Create a new KMS key to use for encryption. Enable EKS secrets encryption using that KMS key on the EKS cluster. This will encrypt secrets in the Kubernetes etcd store. Option A uses Secrets Manager which does not encrypt the etcd store. Option C uses EBS CSI which is unrelated to etcd encryption. Option D enables EBS encryption but does not address etcd encryption.
Comment: EKS supports using AWS KMS keys to provide envelope encryption of Kubernetes secrets stored in EKS. Envelope encryption adds an addition, customer-managed layer of encryption for application secrets or user data that is stored within a Kubernetes cluster. https://eksctl.io/usage/kms-encryption/
Comment: Why not a
Comment: option A does not enable Amazon EKS KMS secrets encryption on the Amazon EKS cluster
Comment: B is the right option. https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html
Comment: It is B, because we need to encrypt inside of the EKS cluster, not outside. AWS KMS is to encrypt at rest.
Comment: is B, not D
Comment: Highly Available = Multi-AZ Cluster Read-only + Near Real time = readable standby. Read replicas are async whereas readable standby is synchronous. https://stackoverflow.com/questions/70663036/differences-b-w-aws-read-replica-and-the-standby-instances
Comment: a Multi-AZ instance deployment is also highly available for a lower cost, no?
Comment: This^ is the reason.
Comment: It's either C or D. To be honest, I find the newest questions to be ridiculously hard (roughly 500+). I agree with @alexandercamachop that Multi Az in Instance mode is cheaper than Cluster. However, with Cluster we have reader endpoint available to use out-of-box, so there is no need to provide read-replicas, which also has its own costs. The ridiculous part is that I'm pretty sure even the AWS support would have troubles to answer which configuration is MOST cost-effective.
Comment: Near real-time is clue for C, since read replicas are async, but still its not obvious question.
Comment: Absolutely true that 500+ questions are damn difficult to answer. I still dont know why is B incorrect. Shouldn't 1 extra be better than 2 ?
Comment: they are not all hard, most are normal. its just this one and that one about EKS encryption control plane (earlier than this page).
Comment: Option D: Multi-AZ cluster deployment with two readable standby instances would be more costly and is not necessary if read replicas are sufficient for the data scientists' needs. Thus, Option C is the most cost-effective and operationally efficient solution to meet the company's requirements.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html
Comment: Not A - Not "highly available" Not B - "Access to the secondary instance" is not possible in Multi-AZ Not C - Multi-AZ + two (!) read replicas is more expensive than cluster D - Provides "readable standby instances"
Comment: D https://aws.amazon.com/about-aws/whats-new/2023/01/amazon-rds-multi-az-readable-standbys-rds-postgresql-inbound-replication/
Comment: https://aws.amazon.com/blogs/database/choose-the-right-amazon-rds-deployment-option-single-az-instance-multi-az-instance-or-multi-az-database-cluster/ C would mean you are paying for 4 instances (primary, backup, and 2 read instances). D would be 3 (primary, and 2 backup). Difficult to be sure, pricing calculator doesn't even include clusters yet.
Comment: Option D is the most cost-effective solution that meets the requirements for this scenario. The key considerations are: Data scientists need read-only access to near real-time production data without affecting performance. High availability is required. Cost should be minimized.
Comment: https://aws.amazon.com/blogs/database/choose-the-right-amazon-rds-deployment-option-single-az-instance-multi-az-instance-or-multi-az-database-cluster/ only multi AZ cluster have reader endpoint. multi AZ instance secondary replicate is not allow to access
Comment: Support for D: Amazon RDS now offers Multi-AZ deployments with readable standby instances (also called Multi-AZ DB cluster deployments) in preview. You should consider using Multi-AZ DB cluster deployments with two readable DB instances if you need additional read capacity in your Amazon RDS Multi-AZ deployment and if your application workload has strict transaction latency requirements such as single-digit milliseconds transactions. https://aws.amazon.com/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/
Comment: Unlike Multi-AZ instance deployment, where the secondary instance can't be accessed for read or writes, Multi-AZ DB cluster deployment consists of primary instance running in one AZ serving read-write traffic and two other standby running in two different AZs serving read traffic.
Comment: D. using Multi-AZ DB cluster deployments with two readable DB instances if you need additional read capacity in your Amazon RDS Multi-AZ deployment and if your application workload has strict transaction latency requirements such as single-digit milliseconds transactions. https://aws.amazon.com/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/ while on read replicas, Amazon RDS then uses the asynchronous replication method for the DB engine to update the read replica whenever there is a change to the primary DB instance. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
Comment: Why not b. Shouldnt it have less number of instances than both c and d?
Comment: Complex queries on single db will affect performance of db
Comment: You can't 'access the secondary instance' as suggested by B
Comment: "The Multi-AZ instance is suitable for business/mission critical applications that require high availability with low RTO/RPO and resilience to availability zone outage. However, this high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic. To serve read-only traffic, use a Multi-AZ DB cluster or a read replica instead."
Comment: Multi-AZ is about twice the price of Single-AZ. For example: db.t2.micro single - $0.017/hour db.t2.micro multi - $0.034/hour option C: 1 primary + 1 standby + 2 replica = 4Db option D: 1 primary + 2 standby = 3Db D. appears to be most cost effective
Comment: I think the best explanation I've read so far.
Comment: D: https://aws.amazon.com/tw/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/
Comment: Forgot to vote
Comment: I think it's D. C: Multi-AZ instance = active + standby + two read replicas = 4 RDS instances D: Multi-AZ cluster = Active + two standby = 3 RDS instances Single-AZ and Multi-AZ deployments: Pricing is billed per DB instance-hour consumed from the time a DB instance is launched until it is stopped or deleted. https://aws.amazon.com/rds/postgresql/pricing/?pg=pr&loc=3 In the case of a cluster, you will pay less.
Comment: Multi-AZ instance: the standby instance doesn't serve any read or write traffic. Multi-AZ DB cluster: consists of primary instance running in one AZ serving read-write traffic and two other standby running in two different AZs serving read traffic. https://aws.amazon.com/blogs/database/choose-the-right-amazon-rds-deployment-option-single-az-instance-multi-az-instance-or-multi-az-database-cluster/
Comment: Memcached is best suited for caching data, while Redis is better for storing data that needs to be persisted. If you need to store data that needs to be accessed frequently, such as user profiles, session data, and application settings, then Redis is the better choice
Comment: and for high availability, it's better than memcached
Comment: but does rds multi-az provide the needed scalability?
Comment: it is multi-az cluster deployment, same as B, so yes, it is providing the needed scalability. Great explanation.
Comment: Replication: Redis supports creating multiple replicas for read scalability and high availability.https://aws.amazon.com/elasticache/redis-vs-memcached/
Comment: A because of "Amazon EC2 web server that hosts user session states" C: RDS to DynamoDB doesn't make total sense D: Single zone is not HA Between A and B, A is suitable because of session state and Elasticache with Redis is more HA than option B
Comment: B: from what I know, Memcached provide better performance and simplicity but lower availability than redis. C: mysql is relational database, dynamodb is nosql D: single AZ
Comment: ElastiCache for Redis supports HA, ElastiCache for Memcached does not: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/SelectEngine.html C could in theory work, but session data is typically stored in ElastiCache, not in DynamoDB. D is not HA.
Comment: 'hosts user session states' in question, thus redis
Comment: Right, but Redis is A
Comment: Redis is a widely adopted in-memory data store for use as a database, cache, message broker, queue, session store, and leaderboard. https://aws.amazon.com/elasticache/redis/
Comment: B is correct. We are left with 2 options: A and B. But it requires that the system be able to scale to meet future application capacity demands. Redis is very good. But its drawback is not scalable. Thats why they implement memcached.
Comment: A Redis as an in-memory data store with high availability and persistence is a popular choice among application developers to store and manage session data for internet-scale applications. Redis provides the sub-millisecond latency, scale, and resiliency required to manage session data such as user profiles, credentials, session state, and user-specific personalization.
Comment: Redis provides replication while memcached doesnt.
Comment: The key reasons why option A is preferable: RDS Multi-AZ provides high availability for MySQL by synchronously replicating data across AZs. Automatic failover handles AZ outages. ElastiCache for Redis is better suited for session data caching than Memcached. Redis offers more advanced data structures and flexibility. Auto scaling across 3 AZs provides high availability for the web tier
Comment: the different between Redis and Memcache is that Memcache suuport multithread process to handle the increase of application traffic. https://aws.amazon.com/elasticache/redis-vs-memcached/
Comment: ElastiCache for Memcached says "No" for "High Availability" https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/SelectEngine.html
Comment: This requirement wins for me: "be able to scale to meet future application capacity demands". Memcached implements a multi-threaded architecture, it can make use of multiple processing cores. This means that you can handle more operations by scaling up compute capacity. https://aws.amazon.com/elasticache/redis-vs-memcached/#:~:text=by%20their%20rank.-,Multithreaded%20architecture,-Since%20Memcached%20is
Comment: cache reads is memcached right?
Comment: B is correct!
Comment: is A not B
Comment: This question asks us to guess Netflix subscription model in 2 mins! lol! BCD are impractical for geo restrictions as you cannot restrict URL by region and you cannot encrypt by geo region (country etc)
Comment: The CloudFront geographic restrictions feature lets you control distribution of your content at the country level for all files that you're distributing with a given web distribution. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
Comment: Add geographic restrictions to the content in CloudFront by using an allow list. Set up a custom error message
Comment: Add geographic restrictions to the content in CloudFront by using an allow list. Set up a custom error message.
Comment: A makes sense - cloudfront has the capabilities of georestriction
Comment: Pretty sure it's A.
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
Comment: is B not A
Comment: How is signed URL going to be geo restricted? Anyone with signed url can access the content on that url regardless of their location so B is wrong.
Comment: Why's that?
Comment: Signed url or cookies can be used for the banner country as well?
Comment: Backup & Restore (RPO in hours, RTO in 24 hours or less) Pilot Light (RPO in minutes, RTO in hours) Warm Standby (RPO in seconds, RTO in minutes) *** Right Answer *** Active-Active (RPO is none or possibly seconds, RTO in seconds)
Comment: https://disaster-recovery.workshop.aws/en/intro/disaster-recovery.html#:~:text=Pilot%20Light%20(RPO%20in%20minutes,that%20includes%20that%20critical%20core.
Comment: Not A - too expensive and not using AWS services Not B - "RDS for SQL Server" does not support everything that "SQL Server Standard which runs on a VM" does; CDC supports even less (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html). Also it would be more expensive than C. Not D - "Every night" would not meet the RPO requirement
Comment: Thanks I was confused between B and C. This makes perfect sense!
Comment: Pilot light (RPO in minutes, RTO in tens of minutes) Warm standby (RPO in seconds, RTO in minutes) https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html
Comment: When cost is a concern, and you wish to achieve a similar RPO and RTO objectives as defined in the warm standby strategy, you could consider cloud native solutions, like AWS Elastic Disaster Recovery, that take the pilot light approach and offer improved RPO and RTO targets.
Comment: AWS DRS(AWS Elastic Disaster Recovery) enables RPOs of seconds and RTOs of minutes.
Comment: https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#warm-standby
Comment: A: Not possible B: With RDS it means your failover will launch a different database engine. This is wrong in general D: No comments C: It is a disk based replication so it will be similar DB server and this is the product managed by AWS for the DR of on-prem setups. https://aws.amazon.com/blogs/modernizing-with-aws/how-to-set-up-disaster-recovery-for-sql-server-always-on-availability-groups-using-aws-elastic-disaster-recovery/
Comment:
AWS Elastic Disaster Recovery
If you are considering the pilot light or warm standby strategy for disaster recovery, AWS Elastic Disaster Recovery could provide an alternative approach with improved benefits. Elastic Disaster Recovery can offer an RPO and RTO target similar to warm standby, but maintain the low-cost approach of pilot light
From
Comment: With the pilot light approach, you replicate your data from one environment to another and provision a copy of your core workload infrastructure, not the fully functional copy of your production environment in a recovery environment.
Comment: https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/
Comment: We have no idea if they are using SQL Server features that require OS customization etc., so we can't assume that the app would run on RDS for SQL Server at all. We need a replica of the VM that SQL Server is currently running on, thus C.
Comment: C: Pilot light - In pilot light, databases are always on, thus minimize RPO (can satisfy the 30s requirement) - Only apps are turn off. But it can satisfy the 60 minutes requirement - Warm standby, of cource, can satisfy all the RPO and RTO requirements, but it is more expensive than pilot light
Comment: B(warm standby) is doable, but C (pilot light) is most cost effectively. https://aws.amazon.com/tw/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/
Comment: The company wants to improve... so needs something guaranteed to be better than 60 mins RTO
Comment: Configure a warm standby Amazon RDS for SQL Server database on AWS. Configure AWS Database Migration Service (AWS DMS) to use change data capture (CDC).
Comment: Warm standby is costlier than Pilot Light
Comment: AWS DRS enables RPOs of seconds and RTOs of minutes. Pilot light is also cheaper than warm standby. https://aws.amazon.com/disaster-recovery/
Comment: C is correct. Since it is not only your core elements that are running all the time, warm standby is usually more costly than pilot light. Warm standby is another example of active/passive failover configuration. Servers can be left running in a minimum number of EC2 instances on the smallest sizes possible. Ref: https://tutorialsdojo.com/backup-and-restore-vs-pilot-light-vs-warm-standby-vs-multi-site/#:~:text=Since%20it%20is%20not%20only,on%20the%20smallest%20sizes%20possible.
Comment: https://aws.amazon.com/ko/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/ It says Pilot Light costs less than Warm Standby.
Comment: https://stepstocloud.com/change-data-capture/?expand_article=1
Comment: Based on this link Change Data Capture (CDC) in AWS is a mechanism for tracking changes to data in DynamoDB tables. And the question refers to Microsoft SQL Server Standard
Comment: ok, it's also fror SQL servers: SQL Server Change Data Capture (CDC) is a feature that enables you to capture insert, update, and delete activity on a SQL Server table,
Comment: Yeah, but still it doesn't make sense here, it does not support various SQL Server features.
Comment: Answer C. RPO is in seconds and RTO 5-20 min; pilot light costs less than warm standby (and of course less than active-active). https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html#recovery-objectives
Comment: Its D Multi-AZ DB clusters aren't available with the following engines: RDS for MariaDB RDS for Oracle RDS for SQL Server https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.html
Comment: C. Use Amazon RDS deployed in a Multi-AZ cluster deployment to create an Oracle database. Direct the reporting functions to use the reader instance in the cluster deployment. A and B discarted. The answer is between C and D D says use an Amazon RDS to build an Amazon Aurora, makes no sense. C is the correct one, high availability in multi az deployment. Also point the reporting to the reader replica.
Comment: Multi-AZ DB clusters aren't available with the following engines: RDS for MariaDB RDS for Oracle RDS for SQL Server
Comment: using RDS to build Aurora from an Oracle DB https://aws.amazon.com/tutorials/break-free-from-legacy-databases/migrate-oracle-to-amazon-aurora/
Comment: Multi-AZ (Availability Zone) deployments are not available for the following Amazon RDS database engines: 1. Amazon Aurora with MySQL compatibility 2. Amazon Aurora with PostgreSQL compatibility 3. Amazon RDS for SQL Server Express Edition 4. Amazon RDS for Oracle Standard Edition One 5. Amazon RDS for Oracle Standard Edition 6. Amazon RDS for Oracle SE2 (Standard Edition 2) For these database engines, Amazon RDS provides high availability using other mechanisms specific to each engine, such as Read Replicas or different standby configurations. However, Multi-AZ deployments, which automatically provision and maintain a synchronous standby replica in a different Availability Zone for failover support, are not supported for these engines.
Comment: this link expalins why the answer is C and confirms that rds for oracle supports multi-AZ https://aws.amazon.com/blogs/aws/multi-az-option-for-amazon-rds-oracle/
Comment: requiring high availability and performance.https://aws.amazon.com/rds/aurora/
Comment: Between C&D, D is correct as C is not possible: https://aws.amazon.com/blogs/aws/multi-az-option-for-amazon-rds-oracle/
Comment: Not A - Creating multiple instances and keeping them in sync in DMS is surely not "operationally efficient" Not B - "replica in the same zone" -> does not provide "higher availability" Not C - "Multi-AZ cluster" does not support Oracle engine Thus D. Question does not mention that the app would use Oracle-specific features; we're also not asked to minimize application changes. Ideal solution from AWS point of view is to move from Oracle to Aurora.
Comment: but Aurora doesnt support oracle db though
Comment: i am sure just look here https://aws.amazon.com/ar/blogs/aws/amazon-rds-multi-az-db-cluster/
Comment: sorry this is the right link: https://aws.amazon.com/ar/blogs/aws/multi-az-option-for-amazon-rds-oracle/
Comment: "Multi-AZ cluster (!)" does not support Oracle. Multi-AZ instance would.
Comment: It should be C. Oracle DB is supported in RDS Multi-AZ with one standby for HA. https://aws.amazon.com/rds/features/multi-az/. Additionally, a reader instance/replica could be added to RDS Multi-AZ with one standby setup to offload the read requests. Aurora is only supported MySQL and Postgres compatible DB so "D" is out.
Comment: https://aws.amazon.com/rds/features/multi-az/ gives:Amazon RDS Multi-AZ is available for RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, and RDS for Db2. Amazon RDS Multi-AZ with two readable standbys is available for RDS for PostgreSQL and RDS for MySQL. So no reader instance.
Comment: Multi-AZ DB clusters are NOT available with the following engines: RDS for MariaDB RDS for Oracle RDS for SQL Server https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.html
Comment: It is C. Aurora database doesn't support Oracle.
Comment: You can use Aurora instead of Oracle. There are tutorials how to migrate Oracle to Aurora. On top C is not supported. The is not Multi-AZ DB CLUSTER for Oracle.
Comment: It is D
Comment: None options seems valid. Not C because it is not supported. But not D as well. RDS is not Aurora. They are two separate services. Additionally, In multi AZ instance deployment, it only provides fault tolerance, not High avai.
Comment: Multi-AZ Cluster does not support Oracle as engine: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.MultiAZDBClusters.html
Comment: D is my choice. Multi-AZ DB cluster does not support Oracle DB.
Comment: Option C is correct one . As there is no option for 'Aurora(Oracle Compatible)'.so this kick out D from race.
Comment: Using RDS Multi-AZ provides high availability and failover capabilities for the primary Oracle database. The reader instance in the Multi-AZ cluster can be used for offloading reporting workloads from the primary instance. This improves performance. RDS Multi-AZ has automatic failover between AZs. DMS and Aurora migrations (A, D) would incur more effort and downtime. Single-AZ with a read replica (B) does not provide the AZ failover capability that Multi-AZ does.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
Comment: If in doubt between E or F. S3 doesn't support server-side scripts, PHP is a server-side script. The answer is ACE. https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html
Comment: Option B (Amazon ECS) is not the best option since the website "can be idle for a long time", so Lambda (Option A) is a more cost-effective choice. Option D is incorrect because User pools are for authentication (identity verification) while Identity pools are for authorization (access control). Option F is wrong because S3 web hosting only supports static web files like HTML/CSS, and does not support PHP or JavaScript.
Comment: https://aws.amazon.com/getting-started/projects/build-serverless-web-app-lambda-apigateway-s3-dynamodb-cognito/module-1/?nc1=h_ls
Comment: I will go for A C E
Comment: A: App may be idle for long time so Lambda is perfect (charge per invocation) C: Cognito user pool for user auth E: Amplify is low code web dev tool B: Wrong, too much cost when idle D: Identity pool is session management/identification. Does not help with auth. F: S3 + PHP doesn't work also no security
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html S3 doesn't support server-side scripting
Comment: User Pool = authentication Identity Pool = authorization
Comment: A D F: A: for hosting the dynamic content of the app. Pay as execution D: for granting temporary privilege access to users who has paid a fee. F: for hosting the static content of the app
Comment: There is no static content in this web application so F is wrong. You cannot host PHP on S3 also so it is just wrong.
Comment: ACE is correct answer
Comment: C) Create an Amazon Cognito user pool to authenticate users. E) Use AWS Amplify to serve the frontend web content with HTML, CSS, and JS. Use an integrated CloudFront configuration. F) Use Amazon S3 static web hosting with PHP, CSS, and JS. Use Amazon CloudFront to serve the frontend web content.
Comment: There is no static content in this web application so F is wrong. You cannot host PHP on S3 also so it is just wrong.
Comment: Build a web application = AWS Amplify Sign in users = Amazon Cognito user pool Traffic can be idle for a long time = AWS Lambda Amazon S3 does not support server-side scripting such as PHP, JSP, or ASP.NET. https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html?icmpid=docs_amazons3_console#:~:text=website%20relies%20on-,server%2Dside,-processing%2C%20including%20server Traffic can be idle for a long time = AWS Lambda
Comment: Use exclusion method: No need for Container (no need run all time), remove B. PHP cannot run with static Amazon S3, remove F. Use selection method: Idle for sometime, choose AWS Lambda, choose A. “Amazon Cognito is an identity platform for web and mobile apps.” (https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html ), choose C. Create an identity pool https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-identity-pool.html . AWS Amplify https://aws.amazon.com/amplify/ for build full-stack web-app in hours.
Comment: Ans: ACF use AWS SDK for PHP/JS with S3 https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/php_s3_code_examples.html
Comment: did you actually read the link or just copy the first link from google here? the sdk is intended for usage in a php application. it does not say anything about php support in a s3 bucket
Comment: Answer is ACE
Comment: Lambda =serverless User Pool = For user authentication Amplify = hosting web/mobile apps
Comment: S3 doesn't support PHP as stated in answer F. https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html
Comment: I don't think S3 can handle anything dynamic such as PHP. So I go for ACE
Comment: ACF no doubt. Check the difference between user pools and identity pools.
Comment: This question page is filled with premium customers I just can't
Comment: CloudFront Signed URL with Custom Policy are exactly for this. A: Nope, cookies don't help as they don't restrict URL C: Wrong. OAC for non-premium customers, how is that even possible without any details here? D: Field encryption, while good idea, does not help restricting the content by customer
Comment: Authentication is done by Cloudfront, thus B
Comment: Content on demand = CloudFront. B
Comment: Generate and provide CloudFront signed URLs to premium customers.
Comment: Use CloudFront signed URLs or signed cookies to restrict access to documents, business data, media streams, or content that is intended for selected users, for example, users who have paid a fee. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html#:~:text=CloudFront%20signed%20URLs
Comment: See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html#private-content-how-signed-urls-work
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html Notice that A is not correct because it should be CloudFront signed URL, not S3.
Comment: Why not C?
Comment: https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-introduces-origin-access-control-oac/
Comment: OAC requires the consumers to have an IAM role with access to the S3 content, this is not what we're after here.
Comment: Signed URLs https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
Comment: Then why A is incorrect?
Comment: Because Authentication is done by Cloudfront, not S3.
Comment: i had this question today
Comment: For me, E makes no sense as the discount is with a new payer and cannot be transferred to an existing account unless customer service is involved.
Comment: Also, "A company runs Amazon EC2 instances in multiple AWS accounts that are individually bled" It's not bled, it is "billed"
Comment: Organization should be created by a new account that is reserved for management. Thus D, followed by A (discount sharing must be enabled in the management account).
Comment: AE https://repost.aws/questions/QUQoJuQLNOTDiyEuCLARlBFQ/transfer-savings-plan-across-organizations#:~:text=AWS%20Support%20can%20transfer%20Savings%20Plans%20from%20the%20management%20account%20to%20a%20member%20account%20or%20from%20a%20member%20account%20to%20the%20management%20account%20within%20a%20single%20Organization%20with%20an%20AWS%20Support%20Case.
Comment: It is not recommended to have workload on the management account.
Comment: Not E - it mentions using an account with existing EC2s as the management account, which goes against the best practice for a management account https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html
Comment: AE is best
Comment: AE is best
Comment: - B is not accepted, because "include all accounts", remove B. - D has "Create an organization in AWS Organization in a new payer acocunt", it is wrong, remove D. - at C: AWS Resource Access Manager (AWS RAM) https://aws.amazon.com/ram/ it is for security, not for billing. Remove C. Has A, E remain, and choosed. A. "turn on discount sharing" is ok. This case: Has discount for many EC2 instances in one account, then want to share with other user. At E, create Organization, then share.
Comment: What is the problem with "include all accounts"?
Comment: I vote AE.
Comment: AE are correct !
Comment: It's not good practice to create a payer account with any workload so it must be D. By the reason that we need Organizations for sharing, then we need to turn on its from our PAYER account. (all sub-accounts start share discounts)
Comment: changed to AD
Comment: @alexandercamachop it is AE. I believe its just typo. RAM is not needed anyhow.
Comment: You are right https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html
Comment: C & E for sure. In order to share savings plans, we need an organization. Create that organization first and then invite everyone to it. From that console share it other accounts.
Comment: We made it all the way here. Good luck everyone!
Comment: what are the total number of questions this package has as on 14 July 2023 , is it 544 or 551 ?
Comment: August 2024 - 981 questions :'(
Comment: March 2024 its 825 questions. Constantly adding. Doe ur question, ExamTopic always shows a few more question in listing compared to actual number
Comment: It's 20th of Feb 2024, and it's 798 (it says 804 at the top I donno why tho)
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html
Comment: In a canary release deployment, total API traffic is separated at random into a production release and a canary release with a pre-configured ratio. Typically, the canary release receives a small percentage of API traffic and the production release takes up the rest. The updated API features are only visible to API traffic through the canary. You can adjust the canary traffic percentage to optimize test coverage or performance. https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html
Comment: Using a canary release deployment allows incremental rollout of the new API version to a percentage of traffic. This minimizes impact on customers and potential data loss during the release.
Comment: Minimal effects on customers and minimal data loss = Canary deployment
Comment: Key word "canary release". See this term in See: https://www.jetbrains.com/teamcity/ci-cd-guide/concepts/canary-release/ and/or https://martinfowler.com/bliki/CanaryRelease.html
Comment: keyword: "latest versions on an api" Canary release is a software development strategy in which a "new version of an API" (as well as other software) is deployed for testing purposes.
Comment: It's A
Comment: A. Create a canary release deployment stage for API Gateway. Deploy the latest API version. Point an appropriate percentage of traffic to the canary stage. After API verification, promote the canary stage to the production stage. Canary release meaning only certain percentage of the users.
Comment: Set up a Route 53 active-passive failover configuration. Direct traffic to a static error page that is hosted in an Amazon S3 bucket when Route 53 health checks determine that the ALB endpoint is unhealthy.
Comment: B is correct
Comment: Setting up a Route 53 active-passive failover configuration with the ALB as the primary endpoint and an Amazon S3 static website as the passive endpoint meets the requirements with minimal overhead. Route 53 health checks can monitor the ALB health. If the ALB becomes unhealthy, traffic will automatically failover to the S3 static website. This provides automatic failover with minimal configuration changes
Comment: Sorry. I mean B
Comment: B is correct
Comment: B seems correct
Comment: B is correct.. https://repost.aws/knowledge-center/fail-over-s3-r53
Comment: Nice link find!
Comment: Tape... lol The company must preserve it's existing investment so they want to keep using existing applications. This means EFS won't work. and NFS may not be compatible. VTL is the only thing that may be compatible with an application workflow that backups to tapes. Who the hell comes up with these questions!
Comment: Use Tape Gateway to replace physical tapes on premises with virtual tapes on AWS—reducing your data storage costs without changing your tape-based backup workflows. Tape Gateway supports all leading backup applications and caches virtual tapes on premises for low-latency data access. It compresses your tape data, encrypts it, and stores it in a virtual tape library in Amazon Simple Storage Service (Amazon S3). From there, you can transfer it to either Amazon S3 Glacier Flexible Retrieval or Amazon S3 Glacier Deep Archive to help minimize your long-term storage costs. https://aws.amazon.com/storagegateway/vtl/#:~:text=Use-,Tape%20Gateway,-to%20replace%20physical
Comment: Tape Gateway is use for attache with app.
Comment: Option says it all
Comment: Tape Gateway enables you to replace using physical tapes on premises with virtual tapes in AWS without changing existing backup workflows. Tape Gateway supports all leading backup applications and caches virtual tapes on premises for low-latency data access. Tape Gateway encrypts data between the gateway and AWS for secure data transfer, and compresses data and transitions virtual tapes between Amazon S3 and Amazon S3 Glacier Flexible Retrieval, or Amazon S3 Glacier Deep Archive, to minimize storage costs.
Comment: https://aws.amazon.com/storagegateway/vtl/?nc1=h_ls
Comment: Set up AWS Storage Gateway to connect with the backup applications using the iSCSI-virtual tape library (VTL) interface.
Comment: D is correct https://aws.amazon.com/storagegateway/vtl/?nc1=h_ls
Comment: Amazon Kinesis Data Firehose is a fully managed service for delivering real-time streaming data to destinations such as Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, and Splunk. It requires minimal setup and maintenance, automatically scales to match the throughput of your data, and offers near real-time data delivery with minimal operational overhead.
Comment: High volume streaming data = Kinesis B: Glue is for ETL (to S3 is ok) but not for streaming C: Lambda more overhead D: Streaming != Data migration
Comment: sensor data = Kinesis
Comment: Amazon Kinesis Data Firehose: Capture, transform, and load data streams into AWS data stores (S3) in near real-time. https://aws.amazon.com/pm/kinesis/?gclid=CjwKCAiAu9yqBhBmEiwAHTx5px9z182o0HBEX0BGXU7VeOCOdNpkJMxgbSfvcHlNKN4NHVnbEa0Y1xoCuU0QAvD_BwE&trk=239a97c0-9c5d-42a5-ac65-7381b62f3756≻_channel=ps&ef_id=CjwKCAiAu9yqBhBmEiwAHTx5px9z182o0HBEX0BGXU7VeOCOdNpkJMxgbSfvcHlNKN4NHVnbEa0Y1xoCuU0QAvD_BwE:G:s&s_kwcid=AL!4422!3!651612444428!e!!g!!kinesis%20firehose!19836376048!149982297311#:~:text=Kinesis%20Data%20Firehose-,Capture%2C,-transform%2C%20and%20load
Comment: A for sure
Comment: Correct Answer: A
Comment: A is the answer, near real-time = Kinesis Data Firehose.
Comment: Use Amazon Kinesis Data Firehose to deliver streaming data to Amazon S3
Comment: That is A
Comment: Kinesis Data Firehose is only real-time answer
Comment: That is A
Comment: A is the correct answer
Comment: Kinesis = Near Real Time
Comment: Data collection in near real time = Amazon Kinesis Data Firehose
Comment: A is correct..
Comment: Departments = Organizational Units
Comment: Create organization units (OUs) for each department in AWS Organizations. Attach service control policies (SCPs) to the OUs
Comment: Correct Answer: B
Comment: SCPs to centralize permissioning
Comment: Create organization units (OUs) for each department in AWS Organizations. Attach service control policies (SCPs) to the OUs.
Comment: control services --> SCP
Comment: My rational: Scenary is "A company has separate AWS accounts", it is not mentioning anything about use of Organizations or needs related to centralized managment of these accounts. Then, set up a list of products in AWS Service Catalog in the AWS accounts (on each AWS account) is the best way to manage and control the usage of specific AWS services.
Comment: "Separate AWS accounts" just says that it's multiple accounts, it does not indicate that they are NOT connected into a organization. Service Catalog alone does not restrict anything. You'd need to create a service in Service Catalog for everything you're allowing to use, then grant permissions on those services, and you'd need to remove other permissions from everyone. All of which is not mentioned in D. Just "setting up a list of products in AWS Service Catalog in the AWS accounts" will not restrict anyone from doing what he could do before.
Comment: BBBBBBBBB
Comment: To control different AWS account you required AWS Organisation
Comment: B is correct!!!!
Comment: A: Probably an old question so this option is here but NAT instance is overhead C: Not secure as IG opens up a lot of things D: VPG connects to a service B: NG is managed solution. Secure by config
Comment: Deploy a NAT gateway in the public subnets. Modify the private subnet route table to direct all internet-bound traffic to the NAT gateway
Comment: Correct Answer: B
Comment: Deploy a NAT gateway in the public subnets. Modify the private subnet route table to direct all internet-bound traffic to the NAT gateway.
Comment: NAT Gateway is safe
Comment: B is correct
Comment: Answer is A Amazon S3 Glacier: Expedited Retrieval: Provides access to data within 1-5 minutes. Standard Retrieval: Provides access to data within 3-5 hours. Bulk Retrieval: Provides access to data within 5-12 hours. Amazon S3 Glacier Deep Archive: Standard Retrieval: Provides access to data within 12 hours. Bulk Retrieval: Provides access to data within 48 hours.
Comment: All the "....after 7 days" options are wrong. Before you transition objects to S3 Standard-IA or S3 One Zone-IA, you must store them for at least 30 days in Amazon S3 https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#:~:text=Minimum%20Days%20for%20Transition%20to%20S3%20Standard%2DIA%20or%20S3%20One%20Zone%2DIA
Comment: After reading the document from your link, it's clear that NONE of the restrictions apply to S3 standard, but to S3 Standard IA. A is the correct answer.
Comment: This is worth noticing! Glad I came across your comment 1 day before my test.
Comment: so Could I ask is A or C for this question? I voted for A but it seems you had the same question in the exam and it was C? Thanks! I will attend the exam soon.
Comment: the 7 days limitation is only if you want to move from s3 standart to S3 Standard-IA or S3 One Zone-IA, if you move to s3 glacier dont have this limitation, correct answer is A
Comment: Its A ya bunch of nerds
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: C is incorrect. Unsupported lifecycle transitions Amazon S3 does not support any of the following lifecycle transitions. You can't transition from the following: Any storage class to the S3 Standard storage class. Any storage class to the Reduced Redundancy Storage (RRS) class. The S3 Intelligent-Tiering storage class to the S3 Standard-IA storage class. The S3 One Zone-IA storage class to the S3 Intelligent-Tiering, S3 Standard-IA, or S3 Glacier Instant Retrieval storage classes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: BC are lifecycle with tiering and infrequent access which are not required here. D is deep archive and can take hours to retrieve so it is not suitable A is cheapest workable option
Comment: frequent access pattern- Standard.
Comment: Not B - More expensive than A Not C - Intelligent-Tiering moves only objects of at least 128 KB Not D - Glacier Deep Archive takes more than 6 hours to retrieve
Comment: Any option with S3 Intelligent-Tiering is out, this is only required when the access patterns are unknown. From the question the access patterns are well known, enough to tie the frequently accessed reports to S3 standard and transition them to S3 glacier after 7days.
Comment: its A for me
Comment: Tiene mas sentido
Comment: Option A Amazon S3 Glacier Standard Retrieval: Provides access to data within 3-5 hours.
Comment: most cost effective has to be glacier so A With C it is using intelligence tiering which is 30 days minimum from what I have read, I may be wrong on how I read that.
Comment: answer A frequent access during the first week -> keeps data in s3 standard for 7 days stored for several year and retrievable within 6 hours -> can be moved to s3 glacier for data archive purpose
Comment: Its A. Data cannot be transitioned from Intelligent Tiering to Standard IA https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: Check Oayoade comment, before transition, 30 days in S3 the files have to be, young padawans
Comment: Correct Answer: C
Comment: The key considerations are: The company needs flexibility to change EC2 instance types and families every 2-3 months. This rules out Reserved Instances which lock you into an instance type and family for 1-3 years. A Compute Savings Plan allows switching instance types and families freely within the term as needed. No Upfront is more flexible than All Upfront. A 1-year term balances commitment and flexibility better than a 3-year term given the company's changing needs. With No Upfront, the company only pays for usage monthly without an upfront payment. This optimizes cost.
Comment: "EC2 Instance Savings Plans give you the flexibility to change your usage between instances WITHIN a family in that region. " https://aws.amazon.com/savingsplans/compute-pricing/
Comment: Only Compute Savings Plan allows you to change instance family.
Comment: " needs to change the type and family of its EC2 instances". that means B I think.
Comment: B is the right answer
Comment: B is correct.. 'EC2 Instance Savings Plans' can't change 'family'.
Comment: Correct B. To change 'Family' always Compute saving plan, right?
Comment: The key reasons are: Amazon Macie is designed specifically for discovering and classifying sensitive data like PII in S3. This makes it the optimal service to use. Macie can be enabled directly in the required Regions rather than enabling it across all Regions which is unnecessary. This minimizes overhead. Macie can be set up to automatically scan the specified S3 buckets on a schedule. No need to create separate jobs. Security Hub is for security monitoring across AWS accounts, not specific for PII discovery. More overhead than needed. Inspector and GuardDuty are not built for PII discovery in S3 buckets. They provide broader security capabilities.
Comment: PII = Macie Security Hub: Organisation security and logging not for PII Inspector: Infra vulnerability management GuardDuty: Network protection
Comment: Amazon Macie = PII
Comment: AWS Macie = PII detection
Comment: Amazon Macie will identify all PII
Comment: Since both the app and database have high memory needs, the memory optimized family like R5 instances meet those requirements well. Using the same instance family simplifies management and operations, rather than mixing instance types. Compute optimized instances may not provide enough memory for the SAP app's needs. Storage optimized is overkill for the database's compute and memory needs. HPC is overprovisioned for the SAP app.
Comment: Use the memory optimized instance family for both the application and the database
Comment: High memory utilization = memory optimized. C is the answer
Comment: I thyink its C
Comment: An interface VPC endpoint is a private way to connect to AWS services without having to expose your VPC to the public internet. This is the most secure way to connect to Amazon SQS from the private subnets. Configuring the endpoint to use the private subnets ensures that the traffic between the EC2 instances and the SQS queue is only within the VPC. This helps to protect the traffic from being intercepted by a malicious actor. Adding a security group to the endpoint that has an inbound access rule that allows traffic from the EC2 instances that are in the private subnets further restricts the traffic to only the authorized sources. This helps to prevent unauthorized access to the SQS queue.
Comment: A is correct. B,C: 'Configuring endpoints to use public subnets' --> Invalid D: No Gateway Endpoint for SQS.
Comment: BC are using public subnets so not useful for security D uses gateway endpoint which is not useful to connect to SQS A: https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html
Comment: Sorry, the link is wrong for A. Please ignore it!
Comment: A seems the most suitable, but security group can't add to the endpoint derectly, right?
Comment: Answer is A
Comment: Interface endpoints enable connectivity to services over AWS PrivateLink. It is a collection of one or more elastic network interfaces with a private IP address that serves as an entry point for traffic destined to a supported service. Implement an interface VPC endpoint for Amazon SQS. Configure the endpoint to use the private subnets. Add to the endpoint a security group that has an inbound access rule that allows traffic from the EC2 instances that are in the private subnets.
Comment: A is correct
Comment: I think its A
Comment: best practice is using IAM role for database access. From app to DB => need both read & write, only B meets these 2
Comment: Application "stores and retrieves" data in DynamoDB while A grants only access "to read".
Comment: B is correct, A total wrong because "read the DynamoDB tables", so what about write in database.
Comment: question says: ...application tier stores and retrieves user data in Amazon DynamoDB tables... so it needs read and write access A) is only read access B) seems to be the right answer
Comment: Option B is the correct approach to meet the requirements: Create an IAM role with permissions to access DynamoDB Add the IAM role to an EC2 Instance Profile Associate the Instance Profile with the application EC2 instances This allows the instances to assume the IAM role to obtain temporary credentials to access DynamoDB.
Comment: Explanation. Both A and B seems suitable. But Option A is incorrect because it says “Associate the role with the application instances by referencing an instance profile”. Which just only a Part of the solution. In API/AWS CLI following steps are required to complete the Role-> instance profile association-> to instance. 1. Create an IAM Role 2. add-role-to-instance-profile (aws iam add-role-to-instance-profile --role-name S3Access --instance-profile-name Webserver) 3. associate-iam-instance-profile (aws ec2 associate-iam-instance-profile --instance-id i-123456789abcde123 --iam-instance-profile Name=admin-role) hence Option B is correct.
Comment: Why "No read and write" ? The question clearly states that application tier STORE and RETRIEVE the data from DynamoDB. Which means write and read... I think answer should be B
Comment: https://www.examtopics.com/discussions/amazon/view/80755-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: My rationl: Option A is wrong because the scenario says "stores and retrieves user data in Amazon DynamoDB tables", STORES and RETRIVE, if you set a role to READ, you can write on DinamoDB database
Comment: AAAAAAAAA
Comment: No because it grants only read access
Comment: A is correct
Comment: No because it grants only read access
Comment: Option B is the correct solution that meets the requirements: Use Amazon EMR to process the semi-structured data in Amazon S3. EMR provides a managed Hadoop framework optimized for processing large datasets in S3. EMR supports parallel data processing across multiple nodes to speed up the processing. EMR can integrate directly with Amazon Redshift using the EMR-Redshift integration. This allows querying the Redshift data from EMR and joining it with the S3 data. This enables enriching the semi-structured S3 data with the information stored in Redshift
Comment: By combining AWS Glue and Amazon Redshift, you can process the semistructured data in parallel using Glue ETL jobs and then store the processed and enriched data in a structured format in Amazon Redshift. This approach allows you to perform complex analytics efficiently and at scale.
Comment: D: not relevant, data is semistructured and Glue is more batch than stream data A: not correct, Athena is for querying data B & C look ok but C is out => redundant with Kinesis data stream; EMR already processed data as input into Redshift for parallel processing Only B is most logical
Comment: Key requirement: parallel data processing parallel data processing is EMR (Kind of Apache Hadoop) so it only leave B and C C is Kinesis to Redshift which is pointless logic here B EMR for S3 and EMR for Redshift gives maximum parallel processing here
Comment: A has a pitfall, "use Amazon Athena to PROCESS the data". With Athena you can query, not process, data. C is wrong because Kinesis has no place here. D is wrong because it does not process the Redshift data, and Glue does ETL, not analyze Thus it's B. EMR can use semi-structured data from from S3 and structured data from Redshift and is ideal for "parallel data processing" of "large amounts" of data.
Comment: large amount of data + parallel data processing = EMR
Comment: Amazon Athena is an interactive query service that makes it easy to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL.
Comment: Y, but A says "process", not "query" data with Athena.
Comment: Selected Answer: D Glue use apache pyspark cluster for parallel processing. EMR or Glue are possible options. Glue is serverless so better use this plus pyspark is in memory parallel processing.
Comment: i think a is correct semistructured data ==> Athena
Comment: "Hadoop [as used by EMR] helps you turn petabytes of un-structured or semi-structured data into useful insights" https://aws.amazon.com/emr/features/hadoop/
Comment: Athena is not designed for parallel data processing. So it's B
Comment: Answer is A
Comment: From this documentation looks like EMR cannot interface with S3. https://aws.amazon.com/emr/ I will settle with option A.
Comment: Of course EMR can access S3 https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-file-systems.html
Comment: For those answering A, AWS Glue can directly query S3, it can't use Athena as a source of data. The questions say the Redshift data should be user to "enrich" which means thats the redshift data needs to be "added" to the s3 data. A doesn't allow that.
Comment: Choose option B. Option A is not correct. Amazon Athena is suitable for querying data directly from S3 using SQL and allows parallel processing of S3 data. AWS Glue can be used for data preparation and enrichment but might not directly integrate with Amazon Redshift for enrichment.
Comment: Athena and Redshift both do SQL query
Comment: semi-structure supported by Athena not by EMR
Comment: "Hadoop helps you turn petabytes of un-structured or semi-structured data into useful insights about your applications or users." https://aws.amazon.com/emr/features/hadoop/?nc1=h_ls
Comment: athena for s3
Comment: A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account. The VPCs can be in different Regions (also known as an inter-Region VPC peering connection). https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html#:~:text=A-,VPC%20peering,-connection%20is%20a
Comment: Transit Gateway network peering. VPC Peering to peer 2 or more VPC in the same region.
Comment: The key reasons are: VPC peering provides private connectivity between VPCs without using public IP space. Data transferred between peered VPCs is free as long as they are in the same region. 500 GB/month inter-VPC data transfer fits within peering free tier. Transit Gateway (Option A) incurs hourly charges plus data transfer fees. More costly than peering. Site-to-Site VPN (Option B) incurs hourly charges and data transfer fees. More expensive than peering. Direct Connect (Option D) has high hourly charges and would be overkill for this use case.
Comment: VPC peering is the most cost-effective solution
Comment: Communicating with two VPC in same account = VPC Peering
Comment: C is the correct answer. VPC peering is the most cost-effective way to connect two VPCs within the same region and AWS account. There are no additional charges for VPC peering beyond standard data transfer rates. Transit Gateway and VPN add additional hourly and data processing charges that are not necessary for simple VPC peering. Direct Connect provides dedicated network connectivity, but is overkill for the relatively low inter-VPC data transfer needs described here. It has high fixed costs plus data transfer rates. For occasional inter-VPC communication of moderate data volumes within the same region and account, VPC peering is the most cost-effective solution. It provides simple private connectivity without transfer charges or network appliances.
Comment: The reasons are: User-defined tags were created by each product team to identify resources. Selecting the relevant tag in the Billing console will group costs. The tag must be activated from the Organizations management account to consolidate billing across all accounts. AWS generated tags are predefined by AWS and won't align to product lines. Resource Groups (Option C) helps manage resources but not billing. Activating the tag from each account (Option D) is not needed since Organizations centralizes billing.
Comment: Your user-defined cost allocation tags represent the tag key, which you activate in the Billing console.
Comment: BE BE BE BE
Comment: "Only a management account in an organization and single accounts that aren't members of an organization have access to the cost allocation tags manager in the Billing and Cost Management console." https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html
Comment: The key advantages you highlight of Control Tower are convincing: Fully managed service simplifies multi-account setup. Built-in account drift notifications detect OU changes automatically. More scalable and less complex than Config rules or CloudTrail. Better security and compliance guardrails than custom options. Lower operational overhead compared to other solution
Comment: A is correct. https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html https://docs.aws.amazon.com/controltower/latest/userguide/prevention-and-notification.html
Comment: Create Accounts using AWS Service Catalog: Utilize AWS Service Catalog to provision AWS accounts within AWS Organizations. This ensures standardized account creation and management. Enable AWS CloudTrail Organization Trail: Set up an AWS CloudTrail organization trail that records all API calls across all accounts in the organization. This trail will capture changes to the OU hierarchy, including any modifications to organizational units.
Comment: AWS Config helps you maintain a detailed inventory of your resources and their configurations, track changes over time, and ensure compliance with your organization's policies and industry regulations.
Comment: Furthermore, AWS Config Aggregated Rules are a feature within AWS Config that enables you to evaluate compliance with desired configurations or compliance standards across multiple AWS accounts and regions. They are particularly useful in scenarios where you want to enforce consistent rules and compliance checks across an entire organization with multiple AWS accounts.
Comment: NVM - This is such a stupid question lol changing my answer to A due to the following: Account drift notifications in AWS are a feature provided by AWS Control Tower. These notifications help organizations identify and respond to changes made to an AWS account that deviate from the established baseline configuration created during the initial setup by AWS Control Tower. Drift refers to any configuration changes that have been made to an AWS account after it was provisioned by Control Tower.
Comment: This was in my exam today..I selected Answer A
Comment: what percentage of all these questions would you say were in the exam?
Comment: I read in one of the earlier questions, its around 75%, someone who gave the exam said so
Comment: A https://docs.aws.amazon.com/controltower/latest/userguide/drift.html
Comment: AWS Control Tower provides passive and active methods of drift monitoring protection for preventive controls.
Comment: https://docs.aws.amazon.com/controltower/latest/userguide/prevention-and-notification.html
Comment: A , because B,C and D contains Elasticache which required a heavy code changes, so more operational overhead
Comment: DAX to reduce latency
Comment: decrease latency when retrieving product details from the Amazon DynamoDB = Amazon DynamoDB Accelerator (DAX)
Comment: The key reasons: DAX provides a DynamoDB-compatible caching layer to reduce read latency. It is purpose-built for accelerating DynamoDB workloads. Using DAX requires minimal application changes - only read requests are routed through it. DAX handles caching logic automatically without needing complex integration code. ElastiCache Redis/Memcached (Options B/C) require more integration work to sync DynamoDB data. Using Lambda and Streams to populate ElastiCache (Option D) is a complex event-driven approach requiring ongoing maintenance. DAX plugs in seamlessly to accelerate DynamoDB with very little operational overhead
Comment: DynamoDB = DAX
Comment: only A
Comment: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-ddb.html
Comment: The reasons are: A gateway endpoint for DynamoDB enables private connectivity between DynamoDB and the VPC. This allows EC2 instances to access DynamoDB APIs without traversing the internet. A security group entry is needed to allow the EC2 instances access to the DynamoDB endpoint over the VPC. An interface endpoint is used for services like S3 and Systems Manager, not DynamoDB. Route table entries route traffic within a VPC but do not affect external connectivity. Elastic network interfaces are not needed for gateway endpoints.
Comment: "The outbound rules for the security group for instances that access DynamoDB through the gateway endpoint must allow traffic to DynamoDB", https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-ddb.html The option however is talking about the security group of the endpoint
Comment: A & B are correct https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html E is incorrect. There's no need for security group. From the URL above: "Once the VPC subnet's gateway endpoint has been granted access to DynamoDB, any AWS account with access to that subnet can use DynamoDB."
Comment: Creating the gateway endpoint and edit the route table is enough, there are no secruity group involved
Comment: AB https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html
Comment: C & D are both not relevant. D looks ok but DynamoDB doesn't go with security group, it only allows route table for VPC endpoint. Link here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html
Comment: Sorry, E not D. E looks ok but DynamoDB doesn't go with security group, it only allows route table for VPC endpoint. Link here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html
Comment: DynamoDB can only be connected via Gateway endpoint (just like S3) route table for connecting the VPC tor the endpoint So do B then A C: interface endpoint for EC2 to what? D: ENI not applicable here for VPC E: Incomplete option as to access to what?
Comment: go through this video it will show the answer is AB https://www.youtube.com/watch?v=8FTnyhklEvU
Comment: Gateway Endpoint does not have an ENI, thus it has no security group. Instances have security groups and those must allow access to DynamoDB.
Comment: A. Create a route table entry for the endpoint: This is not necessary, as the gateway endpoint itself automatically creates the required route table entries.
Comment: Create a gateway endpoint for DynamoDB then create a route table entry for the endpoint
Comment: refer to question 555
Comment: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#vpc-endpoints-routing Traffic from your VPC to Amazon S3 or DynamoDB is routed to the gateway endpoint. Each subnet route table must have a route that sends traffic destined for the service to the gateway endpoint using the prefix list for the service.
Comment: You can access Amazon DynamoDB from your VPC using gateway VPC endpoints. After you create the gateway endpoint, you can add it as a target in your route table for traffic destined from your VPC to DynamoDB.
Comment: It is A and B. Not E because security group does not span VPCs.
Comment: A and B for sure
Comment: B and D.
Comment: B You can use Amazon EKS Connector to register and connect any conformant Kubernetes cluster to AWS and visualize it in the Amazon EKS console. After a cluster is connected, you can see the status, configuration, and workloads for that cluster in the Amazon EKS console. You can use this feature to view connected clusters in Amazon EKS console, but you can't manage them. The Amazon EKS Connector requires an agent that is an open source project on Github. For additional technical content, including frequently asked questions and troubleshooting, see Troubleshooting issues in Amazon EKS Connector The Amazon EKS Connector can connect the following types of Kubernetes clusters to Amazon EKS. On-premises Kubernetes clusters Self-managed clusters that are running on Amazon EC2 Managed clusters from other cloud providers
Comment: https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html "You can use Amazon EKS Connector to register and connect any conformant Kubernetes cluster to AWS and visualize it in the Amazon EKS console. " B is the right product for this.
Comment: EKS Connector -> 'view clusters and workloads' as requested EKS Anywhere -> create and manage on-premises EKS clusters
Comment: B EKS connector helps to integrate multiple cluster with EKS console. EKS anywhere is Kubernetes Ditro cluster to be deployed on-prem. It is not for integrating with other cluster.
Comment: View all clusters and workloads (incl on-prem) from a central location = Amazon EKS Connector Create and operate Kubernetes clusters on your own infrastructure = Amazon EKS Anywhere https://aws.amazon.com/eks/eks-anywhere/#:~:text=Amazon-,EKS%20Anywhere,-lets%20you%20create https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html#:~:text=You%20can%20use-,Amazon%20EKS%20Connector,-to%20register%20and
Comment: It is B
Comment: Definitely B. "You can use Amazon EKS Connector to register and connect any conformant Kubernetes cluster to AWS and visualize it in the Amazon EKS console. After a cluster is connected, you can see the status, configuration, and workloads for that cluster in the Amazon EKS console. " https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html
Comment: The key reasons: EKS Connector allows registering external Kubernetes clusters (on-premises and otherwise) with Amazon EKS This provides a unified view and management of all clusters within the EKS console. EKS Connector handles keeping resources in sync across connected clusters. This centralized approach minimizes operational overhead compared to using separate tools. CloudWatch Container Insights (Option A) only provides metrics and logs, not cluster management. Systems Manager (Option C) is more general purpose and does not natively integrate with EKS. EKS Anywhere (Option D) would not provide a single pane of glass for external clusters.
Comment: Amazon EKS Connector enables you to create and manage a centralized view of all your Kubernetes clusters, regardless of whether they are Amazon EKS clusters or on-premises Kubernetes clusters. It allows you to register these clusters with your Amazon EKS control plane, providing a unified management interface for all clusters.
Comment: You can use Amazon EKS Connector to register and connect any conformant Kubernetes cluster to AWS and visualize it in the Amazon EKS console. After a cluster is connected, you can see the status, configuration, and workloads for that cluster in the Amazon EKS console. You can use this feature to view connected clusters in Amazon EKS console, but you can't manage them
Comment: only D can connect to on-perm
Comment: No. "The Amazon EKS Connector can connect the following types of Kubernetes clusters to Amazon EKS. On-premises Kubernetes clusters" https://aws.amazon.com/de/eks/eks-anywhere/
Comment: Wrong link, statement is from https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html
Comment: seems B https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html
Comment: Only B https://docs.aws.amazon.com/eks/latest/userguide/eks-connector.html
Comment: The key reasons are: RDS MySQL provides a fully managed database service well suited for an ecommerce application. AWS KMS client-side encryption allows encrypting sensitive data before it hits the database. The data remains encrypted at rest. This protects sensitive customer data from database admins and privileged users. EBS encryption (Option A) protects data at rest but not in use. IAM roles don't prevent admin access. S3 (Option C) encrypts data at rest on the server side. Bucket policies don't restrict admin access. FSx file permissions (Option D) don't prevent admin access to unencrypted data.
Comment: A, C and D would allow the administrator of the storage to access the data. Besides, it is data about "purchase transactions" which is usually stored in a transactional database (such as RDS for MySQL), not in a file or object storage.
Comment: Good thought purchase transactions I had missed that part
Comment: B I want to go with B as question is for database administrator. Also client key encryption is possible in code and KMS can be used for encryption but not using KMS keys. Encrypted data available in DB is of no use to DB admin.
Comment: Answer is option C. option B is not ideal because Amazon RDS for MySQL is a relational database service that is optimized for structured data, not for storing sensitive customer information. Moreover, by using client-side encryption with AWS KMS, you need to encrypt and decrypt the data in your application code, which increases the risk of exposing your data in transit or at rest. You also need to manage the encryption keys yourself, which adds complexity and overhead to your application.
Comment: "optimized for structured data, not for storing sensitive customer information" ... Data related to "purchase transactions" is usually structured; that it contains "sensitive customer information" doesn't change the structured nature.
Comment: eCommerce data and transaction data are ideal for RDS which, when encrypted, is secure even from the DBA.
Comment: I would go for B, because RDS (database admins), but I would like to see as well encryption at rest as well, not only in transit.
Comment: Using client-side encryption we can protect specific fields and guarantee only decryption if the client has access to an API key, we can protect specific fields even from database admins
Comment: For me it's B because of "client-side encryption to encrypt the data"
Comment: keyword - database administrators
Comment: "even from database administrators" -> "Client Side encryption"
Comment: My choice is B
Comment: The key reasons are: DMS provides an easy migration path from MySQL to Aurora while minimizing downtime. Aurora is a MySQL-compatible relational database service that will maintain compatibility with the company's applications. Aurora Auto Scaling allows the database to automatically scale up and down based on demand to handle increased workloads. RDS MySQL (Option A) does not scale as well as the Aurora architecture. Redshift (Option B) is for analytics, not transactional data, and may not be compatible. DynamoDB (Option D) is a NoSQL datastore and lacks MySQL compatibility.
Comment: A is wrong as you cannot use native MySQL tools for migration. Happy to be corrected though! B Redshift is not compatible with MySQL D is DynamoDB C Aurora MySQL is compatible and supports auto scaling
Comment: on-premises MySQL database, transactional data, maintain compatibility, scale automatically = Amazon Aurora migrating the database to the AWS Cloud = AWS Database Migration Service
Comment: Aurora is a MySQL-compatible relational database service
Comment: Aurora is better in autoscaling then RDS
Comment: C is correct A is incorrect. RDS for MySQL does not scale automatically during periods of increased demand. B is incorrect. Redshift is used for data sharing purposes. D is incorrect. you muse change application codes.
Comment: Amazon RDS now supports Storage Auto Scaling
Comment: Correct B. How is Amazon EFS different than Amazon S3? Amazon EFS provides shared access to data using a traditional file sharing permissions model and hierarchical directory structure via the NFSv4 protocol. Applications that access data using a standard file system interface provided through the operating system can use Amazon EFS to take advantage of the scalability and reliability of file storage in the cloud without writing any new code or adjusting applications. Amazon S3 is an object storage platform that uses a simple API for storing and accessing data. Applications that do not require a file system structure and are designed to work with object storage can use Amazon S3 as a massively scalable, durable, low-cost object storage solution.
Comment: https://aws.amazon.com/efs/when-to-choose-efs/
Comment: hierarchical structure =EFS
Comment: Not A because S3 does not allow a "hierarchical directory structure" Not C because Multi-attach does not work "across two Availability Zones" Not D because we need "shared", not synchronized, storage.
Comment: hierarchical directory structure, read and write rapidly and concurrently to shared storage = Amazon Elastic File System
Comment: Best and most concise explanation here. All true.
Comment: Amazon EFS simultaneously supports on-premises servers using a traditional file permissions model, file locking, and hierarchical directory structure through the NFS v4 protocol.
Comment: The key reasons: EFS provides a scalable, high performance NFS file system that can be concurrently accessed from multiple EC2 instances. It supports the hierarchical directory structure needed by the applications. EFS is elastic, growing and shrinking automatically as needed. It can be accessed from instances across AZs, meeting the shared storage requirement. S3 object storage (option A) lacks the file system semantics needed by the apps. EBS volumes (options C and D) are attached to a single instance and would require replication and syncing to share across instances. EFS is purpose-built for this use case of a shared file system across Linux instances and aligns best with the performance, concurrency, and availability needs.
Comment: Going with b
Comment: C and D involve using Amazon EBS volumes, which are block storage. While they can be attached to EC2 instances, they might not provide the same level of shared concurrent access as Amazon EFS. Additionally, synchronizing EBS volumes across different EC2 instances (as in option D) can be complex and error-prone. Therefore, for a scenario where multiple EC2 instances need to rapidly and concurrently access shared storage with a hierarchical directory structure, Amazon EFS is the best solution.
Comment: s3 is flat structure. EBS multi mount only for same available zone
Comment: Because Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances that are in the same Availability Zone. The infra contains 2 AZ's.
Comment: B is the correct answer https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html
Comment: B is the correct answer https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html
Comment: I think that C is the best option coz io2 can share storage and multi attach.
Comment: hierarchial directory structure is present in EFS
Comment: Multi-attach does not work "across two Availability Zones".
Comment: The key reasons are: ° API Gateway removes the need to manage servers to receive the HTTP requests from sensors ° Lambda functions provide a serverless compute layer to process data as needed ° DynamoDB is a fully managed NoSQL database that scales automatically ° This serverless architecture has minimal operational overhead to manage ° Options B, C, and D all require managing EC2 instances which increases ops workload ° Option C also adds SQL Server admin tasks and licensing costs ° Option D uses EFS file storage which requires capacity planning and management
Comment: Options B,C,D involves unwanted operational overheads due to EC2 So A is the right answer
Comment: Thinking of that, there is not many questions about IoT Core, but this product could be an excellent answer for the need.
Comment: Workload runs every hour, must use managed services, more features in the future, LEAST operational overhead = AWS Lambda functions. HTTP requests, must use managed services, more features in the future, LEAST operational overhead = API Gateway. Must use managed services, more features in the future, LEAST operational overhead =Amazon DynamoDB.
Comment: key word is "must use managed services when possible" api ,lambda dynamodb are serverless. so answer is A
Comment: "The workload will receive more features in the future ..." -> DynamoDB
Comment: A seems to be the right answer
Comment: A is correct.
Comment: I think the answer is A.
Comment: Petabyte data on AWS infra with high performance B is Glacier so slow C EBS for petabyte data doesn't work D Storage gateway is for on premise connectivity which is not required
Comment: Storing and viewing engineering drawings = Amazon S3 Support caching to minimize the amount of time that users wait for the engineering drawings to load = Amazon CloudFront
Comment: CF caching and S3 supports petabytes data
Comment: CF allows caching
Comment: The key reasons are: S3 provides highly durable and scalable object storage capable of handling petabytes of data cost-effectively. CloudFront can be used to cache S3 content at the edge, minimizing latency for users and speeding up access to the engineering drawings. The global CloudFront edge network is ideal for caching large amounts of static media like drawings. EBS provides block storage but lacks the scale and durability of S3 for large media files. Glacier is cheaper archival storage but has higher latency unsuited for frequent access. Storage Gateway and ElastiCache may play a role but do not align as well to the main requirements.
Comment: The answer seems A: B : Glacier for archiving C : i dont think EBS scale to petabytes (I am not sure about that) D : it incorrect becasueAll application components will be deployed on the AWS infrastructur
Comment: A is correct
Comment: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html
Comment: "EventBridge sends metrics to Amazon CloudWatch every minute for everything from the number of matched events to the number of times a target is invoked by a rule." from https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html B: SQS, irrelevant C: 'Check for events', this wording is confusing but could mean something in wrong context. I would have chosen C if A wasn't an option D: CloudTrail is for AWS resource monitoring so irrelevant
Comment: A per https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html Not B because SQS is not even involved here Not C because EventBridge sends only metrics, not detailed logs, to CloudWatch Not D, many fall for CloudTrail supposedly recording "API calls", but this is about calls for the EventBridge API to AWS, not calls to 3rd party APIs by EventBridge.
Comment: Option A, "Check for metrics in Amazon CloudWatch in the namespace for AWS/Events," primarily provides aggregated metrics related to EventBridge, but it may not give detailed information about individual events or their specific content. Metrics in CloudWatch can give you an overview of how many events are being processed, but for detailed inspection of events and their conditions, checking CloudWatch Logs (option C) is more appropriate. CloudWatch Logs allow you to see the actual event data and details, providing a more granular view that is useful for troubleshooting and understanding the specifics of why a third-party API is not receiving incoming traffic.
Comment: A Events not generating logs in cloudwatch and cloudtrail. only metric data is available.
Comment: CloudWatch is a monitoring service for AWS resources and applications. CloudTrail is a web service that records API activity in your AWS account. CloudWatch monitors applications and infrastructure performance in the AWS environment. CloudTrail monitors actions in the AWS environment.
Comment: "API activity", referring to AWS APIs. This would record if someone modifies the EventBridge configuration.
Comment: C should be correct, I check in AWS management concole.
Comment: should be A
Comment: Check the trails in AWS CloudTrail for the EventBridge events.
Comment: I think CloudTrail captures management events (such as modifying the EventBridge configuration)
Comment: Amazon CloudWatch Logs is a service that collects and stores logs from Amazon Web Services (AWS) resources. These logs can be used to troubleshoot problems, monitor performance, and audit activity. The other options are incorrect: Option A: CloudWatch metrics are used to track the performance of AWS resources. They are not used to store events. Option B: Amazon SQS dead-letter queues are used to store messages that cannot be delivered to their intended recipients. They are not used to store events. Option D: AWS CloudTrail is a service that records AWS API calls. It can be used to track the activity of EventBridge rules, but it does not store the events themselves.
Comment: *Errata Corrige* A EventBridge sends metrics to Amazon CloudWatch every minute for everything from the number of matched events to the number of times a target is invoked by a rule. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatch-Events-Monitoring-CloudWatch-Metrics.html
Comment: The answer is D: "CloudTrail captures API calls made by or on behalf of your AWS account from the EventBridge console and to EventBridge API operations." (https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-logging-monitoring.html)
Comment: "API calls" to AWS for managing EventBridge. Not "API calls" BY EventBridge to 3rd party APIs.
Comment: The key reasons: AWS CloudTrail provides visibility into EventBridge operations by logging API calls made by EventBridge. Checking the CloudTrail trails will show the PutEvents API calls made when EventBridge rules match an event pattern. CloudTrail will also log the Invoke API call when the rule target is triggered. CloudWatch metrics and logs contain runtime performance data but not info on rule evaluation and targeting. SQS dead letter queues collect failed event deliveries but won't provide insights on successful invocations. CloudTrail is purpose-built to log operational events and API activity so it can confirm if the EventBridge rule is being evaluated and triggering the target as expected.
Comment: Amazon CloudWatch Logs is a service that collects and stores logs from Amazon Web Services (AWS) resources. These logs can be used to troubleshoot problems, monitor performance, and audit activity. The other options are incorrect: Option A: CloudWatch metrics are used to track the performance of AWS resources. They are not used to store events. Option B: Amazon SQS dead-letter queues are used to store messages that cannot be delivered to their intended recipients. They are not used to store events. Option D: AWS CloudTrail is a service that records AWS API calls. It can be used to track the activity of EventBridge rules, but it does not store the events themselves.
Comment: Option A is the most appropriate solution because Amazon EventBridge publishes metrics to Amazon CloudWatch. You can find relevant metrics in the "AWS/Events" namespace, which allows you to monitor the number of events matched by the rule and the number of invocations to the rule's target.
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatch-Events-Monitoring-CloudWatch-Metrics.html
Comment: B is correct. https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html
Comment: A - too much operation overhead, manually provisioning the instances after you receive the reminder from eventbridge B - right answer, as you can scale up the EC2 instances and keep them ready before large overload time C - too much operation overhead in manually scaling D - automatic scaling will scale up the instances after some duration after it has encountered the heavy workload traffic, not ideal
Comment: runs every Friday evening = an Auto Scaling group that has a scheduled action
Comment: The key reasons: Auto Scaling scheduled actions allow defining specific dates/times to scale out or in. This can be used to scale to 6 instances every Friday evening automatically. Scheduled scaling removes the need for manual intervention to scale up/down for the workload. EventBridge reminders and manual scaling require human involvement each week adding overhead. Automatic scaling responds to demand and may not align perfectly to scale out every Friday without additional tuning. Scheduled Auto Scaling actions provide the automation needed to scale for the weekly workload without ongoing operational overhead.
Comment: Predicted period.. So schedule the instance
Comment: B seems to be correct
Comment: When we know the run time is Friday, we can schedule the instance to 6
Comment: Correct B.
Comment: I don't understand why some many people vote B. In ACM, you can either request certificate from Amazon CA or import an existing certificate. There is no option in ACM that allow you to request a certificate that can be signed by third party CA.
Comment: I fully agree
Comment: Hmm AWS is saying: ACM certificates can be used to establish secure communications across the internet or within an internal network. You can request a publicly trusted certificate directly from ACM (an "ACM certificate") or import a publicly trusted certificate issued by a third party. Self-signed certificates are also supported. To provision your organization's internal PKI, you can issue ACM certificates signed by a private certificate authority (CA) created and managed by AWS Private CA. The CA may either reside in your account or be shared with you by a different account. https://docs.aws.amazon.com/acm/latest/userguide/gs.html
Comment: Exactly. You can "import [not create] a publicly trusted certificate issued by a third party".
Comment: AWS Certificate Manager (ACM) is a service that lets you easily provision, manage, and deploy SSL/TLS certificates for use with AWS services and your internal resources. By creating a certificate in ACM that is signed by the third-party CA, the company can meet its requirement for a specific public third-party CA to sign the TLS certificate.
Comment: Sounds like ChatGPT answer, "creating a certificate in ACM that is signed by the third-party CA" is not possible.
Comment: A. Use a local machine to create a certificate that is signed by the third-party CA. Import the certificate into AWS Certificate Manager (ACM). Create an HTTP API in Amazon API Gateway with a custom domain. Configure the custom domain to use the certificate. Reason: Custom Certificate: Allows you to use a certificate signed by the third-party CA. TLSv1.3 Support: API Gateway supports TLSv1.3 for custom domains. Configuration: You can import the third-party CA certificate into ACM and configure API Gateway to use this certificate with a custom domain. This approach meets all the specified requirements by allowing the use of a third-party CA-signed certificate and ensuring the API endpoints use TLSv1.3.
Comment: A is logical answer. BCD are either misworded here or intentionally confusing. Regardless, you cannot create a cert in ACM that is signed by 3rd party CA. You can only import these certs to ACM.
Comment: We can't create third party certificates in ACM.
Comment: Is this a question from the associate or professional exam ??
Comment: ACM can import, but not create, 3rd party certificates. Leaves only A.
Comment: You have already a publicly trusted certificate issued by a third party and you just need to import it in ACM not to creat a new one. So, the correct answer is A which is the only one that importing the certificate in ACM while B, C and D are creating a new one.
Comment: The answer must be A, You can't create a certificate in ACM, read the below link https://docs.aws.amazon.com/acm/latest/userguide/setup.html
Comment: Answer is A: Can I import a third-party certificate and use it with AWS services? Yes. If you want to use a third-party certificate with Amazon CloudFront, Elastic Load Balancing, or Amazon API Gateway, you may import it into ACM using the AWS Management Console, AWS CLI, or ACM APIs. ACM does not manage the renewal process for imported certificates. You can use the AWS Management Console to monitor the expiration dates of an imported certificates and import a new third-party certificate to replace an expiring one.
Comment: It's 22/Nov/2023 and from the console you cant create a certificate in AWS Certificate Manager (ACM) that is signed by the third-party CA. But you could obtain it externally then import it into ACM.
Comment: Option B meets these requirements: - API Gateway HTTP APIs support TLS 1.3 - ACM can import certificates signed by third-party CAs - API Gateway provides REST APIs
Comment: "ACM can import (!) certificates signed by third-party CA", but not create (!) them as B suggests.
Comment: In ACM you can't create a cert signed by another CA. Dude, try it by yourself. There is no such option!
Comment: WHY NOT A?
Comment: Use ACM to create a certificate signed by the third-party CA. ACM integrates with external CAs. Create an API Gateway HTTP API with a custom domain name. Configure the custom domain to use the ACM certificate. API Gateway supports configuring custom domains with ACM certificates. This allows serving the API over TLS using the required third-party certificate and TLS 1.3 support.
Comment: "ACM integrates with external CAs." no
Comment: You can provide certificates for your integrated AWS services either by issuing them directly with ACM or by importing third-party certificates into the ACM management system.
Comment: Should be A. We need to import third-party certificate to ACM.
Comment: The key reasons: Aurora Serverless v2 provides auto-scaling so the database can handle inconsistent workloads and spikes automatically without admin intervention. It can scale down to zero when not in use to minimize costs. The minimum 1 ACU capacity is sufficient to replace the on-prem 2 GiB database based on the info given. Serverless capabilities reduce admin overhead for capacity management. DynamoDB lacks MySQL compatibility and requires more hands-on management. RDS and provisioned Aurora require manually resizing instances to scale, increasing admin overhead.
Comment: > It can scale down to zero when not in use to minimize costs. This part is not correct. Aurora Serverless v1 was able to scale to zero.
Comment: the questions are hard from 500 +
Comment: I dont think these are associate exam questions rather are from AWS professional exam
Comment: Yes, I agree. I have been reading the pro questions and these are copy paste. On the bright side, it prepares you for the next step!
Comment: C. Provision an Amazon Aurora Serverless v2 database with a minimum capacity of 1 Aurora capacity unit (ACU). Suitability: Amazon Aurora Serverless v2 is a good option for applications with variable workloads because it automatically adjusts capacity based on demand. It can handle MySQL-compatible databases and supports auto-scaling. You can set the minimum and maximum capacity based on your needs, making it highly suitable for handling unexpected workload increases with minimal administrative overhead.
Comment: LEAST administrative overhead = Aurora Serverless
Comment: LEAST administrative overhead = Serverless
Comment: serverless = LEAST overhead
Comment: Why not D?
Comment: no autoscaling with RDS
Comment: Because "LEAST administrative overhead" is a requirement. RDS configured with mem requirements is an admin overhead
Comment: C seems to be the right answer Instead of provisioning and managing database servers, you specify Aurora capacity units (ACUs). Each ACU is a combination of approximately 2 gigabytes (GB) of memory, corresponding CPU, and networking. Database storage automatically scales from 10 gibibytes (GiB) to 128 tebibytes (TiB), the same as storage in a standard Aurora DB cluster https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v1.how-it-works.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
Comment: C is correct. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html#aurora-serverless-v2.how-it-works.capacity
Comment: The key reasons: SnapStart keeps functions initialized and ready to respond quickly, eliminating cold starts. SnapStart is optimized for applications without aggressive latency needs, reducing costs. It scales automatically to match traffic spikes, eliminating outliers when scaling up. SnapStart is a native Lambda feature with no additional charges, keeping costs low. Provisioned concurrency incurs charges for always-on capacity reserved. More costly than SnapStart. Increasing timeout and memory do not directly improve startup performance like SnapStart.
Comment: https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html "Lambda SnapStart for Java can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code."
Comment: Also A: Solves concurrency issues not startup B is for execution timeout (don't think that possible if I understand the option correctly) C Memory is not the issue here
Comment: Lambda SnapStart it is. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html#:~:text=RSS-,Lambda%20SnapStart,-for%20Java%20can
Comment: only because its a Java 11 app...if it were any other besides Java I believe Provisioned concurrency could help.
Comment: Lambda SnapStart for Java can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
Comment: https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
Comment: D is correct Lambda SnapStart for Java can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code. The largest contributor to startup latency (often referred to as cold start time) is the time that Lambda spends initializing the function, which includes loading the function's code, starting the runtime, and initializing the function code. With SnapStart, Lambda initializes your function when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access. When you invoke the function version for the first time, and as the invocations scale up, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup latency.
Comment: Both Lambda SnapStart and provisioned concurrency can reduce cold starts and outlier latencies when a function scales up. SnapStart helps you improve startup performance by up to 10x at no extra cost. Provisioned concurrency keeps functions initialized and ready to respond in double-digit milliseconds. Configuring provisioned concurrency incurs charges to your AWS account. Use provisioned concurrency if your application has strict cold start latency requirements. You can't use both SnapStart and provisioned concurrency on the same function version.
Comment: "SnapStart does not support provisioned concurrency, the arm64 architecture, Amazon Elastic File System (Amazon EFS), or ephemeral storage greater than 512 MB." The question says "The company wants to reduce cold starts" This means provisioned concurrency. I'm a little bit confused with D.
Comment: D https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
Comment: D is the answer Lambda SnapStart for Java can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code. The largest contributor to startup latency (often referred to as cold start time) is the time that Lambda spends initializing the function, which includes loading the function's code, starting the runtime, and initializing the function code. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
Comment: D is best!! A is not MOST cost effectly. lambda snapshot is new feature for lambda. https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
Comment: misspell.... lambda snapstart
Comment: why not D It should work
Comment: The key reasons are: Aurora Serverless v2 scales compute capacity automatically based on actual usage, down to zero when not in use. This minimizes costs for intermittent usage. Since it only runs for 2 hours per week, the application is ideal for a serverless architecture like Aurora Serverless. Aurora Serverless v2 charges per second when the database is active, unlike RDS which charges hourly. Aurora Serverless provides higher availability than self-managed MySQL on EC2 or ECS. Using reserved EC2 instances or ECS still incurs charges when not in use versus the fine-grained scaling of serverless. Standard Aurora clusters have a minimum capacity unlike the auto-scaling serverless architecture.
Comment: A is correct, but Aurora Serverless v2 only scales down to 0.5 ACU, not to zero.
Comment: B is wrong because Aurora MySQL cluster will just keep on running for the rest of the week and will be costly. C and D have too much infra bloating so costly
Comment: 2 hours per week = Serverless = A. Recommended for "infrequent, intermittent, or unpredictable workloads"
Comment: Answer is A. Here are the key distinctions: Amazon Aurora: provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. Amazon Aurora Serverless: is an on-demand, auto-scaling configuration for Aurora where the database automatically starts up, shuts down, and scales capacity up or down based on your application's needs. With serverless the db will shut down when not in use.
Comment: Option is A
Comment: ### Aurora Serverless - Automated database instantiation and auto-scaling based on actual usage - Good for infrequent, intermittent or unpredictable workloads - No capacity planning needed - Pay per second, can be more cost-effective
Comment: will go with A Amazon Aurora Serverless v2 is suitable for the most demanding, highly variable workloads. For example, your database usage might be heavy for a short period of time, followed by long periods of light activity or no activity at all.
Comment: "Amazon Aurora Serverless v2 is suitable for the most demanding, highly variable workloads. For example, your database usage might be heavy for a short period of time, followed by long periods of light activity or no activity at all. " https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html
Comment: A. Migrate the existing RDS for MySQL database to an Aurora Serverless v2 MySQL database cluster.
Comment: B seems to be the correct answer, because if we have a predictable workload Aurora database seems to be most cost effective however if we have unpredictable workload aurora serverless seems to be more cost effective because our database will scale up and down for more informations please read this article https://medium.com/trackit/aurora-or-aurora-serverless-v2-which-is-more-cost-effective-bcd12e172dcf
Comment: according to the link, i understand that Aurora Serverless is ideal for sudden peaks in database usage with moderate or minimal usage during other periods of the day. So Answear is A
Comment: True but due to autoscaling - it will be cheaper...check example#1 in the your link.
Comment: Correct Answer is A
Comment: Provisioned RDS (as in B) is good for steady (not "predictable") workloads. In this case, the workload is predictable, but the prediction is that it will be used only 2 hours per week.
Comment: Aurora Serverless is for "infrequent, intermittent, OR unpredictable workloads"
Comment: RDS Multi-AZ DB cluster deployments provide high availability, automatic failover, and increased read capacity. A multi-AZ cluster automatically handles replicating data across AZs in a single region. This maintains operational efficiency as it is natively managed by RDS without needing external replication. DynamoDB global tables involve complex provisioning and requires app changes. RDS read replicas require manual setup and management of replication. RDS Multi-AZ clustering is purpose-built by AWS for HA PostgreSQL deployments and balancing read workloads.
Comment: "A Multi-AZ DB cluster deployment is a semisynchronous, high availability deployment mode of Amazon RDS with two readable replica DB instances."
Comment: multi-AZ addresses both HA & increased read capacity with synchronous data replication between main DB & standby. Read replica is not enough because only increased read capacity not enabling HA, besides the data replication is async
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html "A Multi-AZ DB cluster deployment is a semisynchronous, high availability deployment mode of Amazon RDS with two readable standby DB instances" A: DynamoDB is not Postgres B: Although HA is achieve but it does not increase the read capacity as much as C without additional operational complexity D: Cross region is not a requirement and won't solve the same region HA or read issues
Comment: Multi-AZ DB Cluster Deployment = Aurora
Comment: Multi-AZ DB cluster deployments provides two readable DB instances if you need additional read capacity
Comment: C is correct
Comment: Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower write latency when compared to Multi-AZ DB instance deployments.
Comment: CCCCCCCCCcCCcCcCCCCccccCc
Comment: DB cluster deployment can scale read workloads by adding read replicas. This provides increased capacity for read workloads without impacting the write workload.
Comment: The correct answer is D API Gateway - Endpoint Types • Edge-Optimized (default): For global clients • Requests are routed through the CloudFront Edge locations (improves latency) • The API Gateway still lives in only one region • Regional: • For clients within the same region • Could manually combine with CloudFront (more control over the caching strategies and the distribution) • Private: • Can only be accessed from your VPC using an interface VPC endpoint (ENI) • Use a resource policy to define access
Comment: geographically distributed users + low latency = Edge optimized ednpoint
Comment: An edge-optimized API endpoint typically routes requests to the nearest CloudFront Point of Presence (POP), which could help in cases where your clients are geographically distributed. This is the default endpoint type for API Gateway REST APIs. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#:~:text=API%20endpoint%20typically-,routes,-requests%20to%20the
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html
Comment: An edge-optimized API endpoint typically routes requests to the nearest CloudFront Point of Presence (POP), which could help in cases where your clients are geographically distributed. This is the default endpoint type for API Gateway REST APIs. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html
Comment: Edge-optimized endpoint
Comment: Correct D. Edge-optimized API endpoints An edge-optimized API endpoint is best for geographically distributed clients. API requests are routed to the nearest CloudFront Point of Presence (POP). This is the default endpoint type for API Gateway REST APIs.
Comment: C is correct. "ACM provides managed renewal for your Amazon-issued SSL/TLS certificates. This means that ACM will either renew your certificates automatically (if you are using DNS validation), or it will send you email notices when expiration is approaching. These services are provided for both public and private ACM certificates." https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html
Comment: The key reasons are: AWS Certificate Manager (ACM) provides free public TLS/SSL certificates and handles certificate renewals automatically. Using DNS validation with ACM is operationally efficient since it automatically makes changes to Route 53 rather than requiring manual validation steps. ACM integrates natively with CloudFront distributions for delivering HTTPS content. CloudFront security policies and origin access controls do not issue TLS certificates. Email validation requires manual steps to approve the domain validation emails for each renewal.
Comment: For me, C is the only realistic option as I don't think you can do AB without a lot of complexity. D just makes no sense.
Comment: Use AWS Certificate Manager (ACM) to create a certificate. Use DNS validation for the domain
Comment: C 似乎是正確的
Comment: "DNS Validation is preferred for automation purposes" -- Stephane's course on Udemy
Comment: C seems to be correct
Comment: I think the general product uses DNS rather than email to automate, is the given answer correct?
Comment: Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for Amazon DynamoDB that delivers up to a 10 times performance improvement—from milliseconds to microseconds—even at millions of requests per second. https://aws.amazon.com/dynamodb/dax/#:~:text=Amazon%20DynamoDB%20Accelerator%20(DAX)%20is,millions%20of%20requests%20per%20second.
Comment: Amazon ElastiCache for Redis would help with "caching requests", but not " improve database response" itself.
Comment: DAX is least operations overhead. B: Redshift, although powerful, but is for analytics C: Downgrading to RDS won't help D: EC for Redis is more for persistent caching so would be good but lot of operational overhead
Comment: improve DynamoDB response time from milliseconds to microseconds and to cache requests to the database = DynamoDB Accelerator (DAX)
Comment: Use DynamoDB Accelerator (DAX).
Comment: Which is A, not C.
Comment: Quote A but mark C. You need more coffee mate :)
Comment: A is the right answer
Comment: Correct A.
Comment: The Instance Scheduler on AWS solution automates the starting and stopping of Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Relational Database Service (Amazon RDS) instances. This solution helps reduce operational costs by stopping resources that are not in use and starting them when they are needed. The cost savings can be significant if you leave all of your instances running at full utilization continuously. https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/
Comment: B increases operational overhead C Lambda functions could work but NOT "based on minimum CPU utilization" D might save cost but not as much as A
Comment: A. Use the Instance Scheduler on AWS to configure start and stop schedules
Comment: Why not D?
Comment: How do you actually reduce costs enough to buy upfront instances that you pay for them if you use them 1 h or 24 and it is payed to run 24h. It says that you use this instances 8 hours a day 5 days a week, totaling 40h a week.... so is it the difference from 40h to 168 h?
Comment: When you buy Reserved Instances, the larger the upfront payment, the greater the discount. To maximize your savings, you can pay all up-front and receive the largest discount. Partial up-front RI's offer lower discounts but give you the option to spend less up front. Lastly, you can choose to spend nothing up front and receive a smaller discount, but allowing you to free up capital to spend in other projects. But you need some mechanism to stop on weekend and in night to save cost.
Comment: A https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/solution-overview.html
Comment: Purpose-built scheduling minimizes operational overhead. Aligns instance running time precisely with business hour demands. Maintains backups unlike disabling auto backups. More cost effective and flexible than reserved instances. Simpler to implement than a custom Lambda function.
Comment: Its B. Check the AWS link https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/?nc1=h_ls
Comment: Sorry I wanted to select A.
Comment: A https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/
Comment: Scheduler do the job
Comment: MOST cost-effectively =GP3
Comment: gp3 offers SSD-performance at a 20% lower cost per GB than gp2 volumes.
Comment: GP3 is the lastest version
Comment: GP3 is the lastest version, and it is cost effective
Comment: GP3 is preferable over GP2, FSx for Lustre, and FSx for OpenZFS is clear and convincing: GP3 offers identical latency performance to GP2 at a lower price point. FSx options are higher performance but more expensive and require application changes. GP3 aligns better with lift and shift needs as a directly attached block storage volume.
Comment: Migrate your Amazon EBS volumes from gp2 to gp3 and save up to 20% on costs.
Comment: Y not gp2
Comment: My rational: Options A y C are based on autoscaling-group and no make sense for me on this scenary. Then, use Amazon EBS is the solution and GP2 or GP3 is the question. Requirement requires the most COST effective solution, then, I choose GP3
Comment: By setting the Auto Scaling group's minimum capacity to four, the architect ensures that there are always at least two running instances. Deploying two On-Demand Instances in each of two Availability Zones ensures that the application is highly available and fault-tolerant. If one Availability Zone becomes unavailable, the application can still run in the other Availability Zone.
Comment: My rational is: Highly available = 2 AZ, and then 2 EC2 instances always running is 1 EC2 in each AZ. If an entire AZ fails, SacalinGroup deploy the minimun instances (2) on the running AZ
Comment: Ans: A. The application requires at least two EC2 instances to always be running = 2 minimum capacity… minimum cap of 4 ec2 will work but a waste of resources that doesn't follow well archi. framework.
Comment: it says always have to have two running, hence you need 4. two in each AV. it might be a waste of resource but if that what is required by the company then so be it. Also you out the 4 you cannot use spot instances because if the two instances on the on demand go down and you need to use the spot instance they could be called back at any point.
Comment: AZ * not AV
Comment: Option A: Set the Auto Scaling group's minimum capacity to two. Deploy one On-Demand Instance in one Availability Zone and one On-Demand Instance in a second Availability Zone. This configuration ensures that you have two instances running across two different AZs, which provides high availability. However, it does not take advantage of additional capacity to handle failures or spikes in demand. If either AZ becomes unavailable, you will have one running instance, but this does not meet the requirement of having at least two running instances at all times.
Comment: Set the Auto Scaling group's minimum capacity to four. Deploy two On-Demand Instances in one Availability Zone and two On-Demand Instances in a second Availability Zone. This configuration provides high availability with four instances distributed across two AZs. The minimum capacity of four ensures that even if one instance fails, there are still two instances in each AZ to handle the load. This option is highly available and fault-tolerant but may be more than required if only two instances are needed to be always running.
Comment: Answer is A: If one Availability Zone fails, the Auto Scaling group will automatically launch a new instance in a different, healthy Availability Zone to maintain the desired capacity of two instances. This is one of the key benefits of using Auto Scaling groups—they automatically maintain the desired number of instances across multiple Availability Zones, ensuring that your application is highly available and fault-tolerant. So even in the event of a failure in one Availability Zone, your application will continue to run on the required number of instances. This is why it's recommended to distribute instances across multiple Availability Zones when designing architectures for high availability and fault tolerance.
Comment: so indeed ASG can set up a new EC2 instance in another AZ if there is one AZ failed with fault but it failed to meet the need of always having 2 instance running before the new instance replacement is done in the working AZ. so this is why we deploy 2 instances per AZ
Comment: If it would not mention the "stateful" application, and if it would only have to be "highly available" but NOT "fault-tolerant", A would be fine.
Comment:
From
Comment: The main requirement here is a 'highly available and fault-tolerant architecture for the application', this covered by option B. The application requires at least two EC2 instances to always be running, main word here being 'atleast' which means more than two is ok.
Comment: B - Need 2 in each AZ and you cant use spot instances as it could be recalled.
Comment: Stateful is keyword here. 2 is minimum required all time.
Comment: If a complete AZ fails, autoscale will lunch a second EC2 in the running AZ. If that short period of time is not always, which is not, then the answer is B, but I would take my chances and select A in the exam xD because the application is highly available and fault-tolerant.
Comment: ° Minimum of 4 ensures at least 2 instances are always running in each AZ, meeting the HA requirement. ° On-Demand instances provide consistent performance and availability, unlike Spot. ° Spreading across 2 AZs adds fault tolerance, protecting from AZ failure.
Comment: While Spot Instances can be used to reduce costs, they might not provide the same level of availability and guaranteed uptime that On-Demand Instances offer. So I will go with B and not D.
Comment: Highly available - 2 AZ and then 2 EC2 instances always running. 2 in each AZ.
Comment: Highly available - 2 AZ and then 2 EC2 instances always running. 2 in each AZ..
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html B can be done but definition of "near" is ambiguous C wrong region D wrong solution as splitting evenly does not reduce latency for on-prem server users
Comment: not C. Client do not have AWS us-west-1 region. Client have a on prem DC near west-1 not D. 2 people visit the site together near eu-central-1, one of the user may be thrown to west-1 due to load balancing on split even weighted policy. A and B are both valid, latency = how soon user reach the datacenter and received a responses from the DC, round trip. So in short, geolocation or send user to the nearest DC will improve latency.
Comment: Geolocation routing policy allows you to route traffic based on the location of your users.
Comment: C. Set up a latency routing policy. Associate the policy with us-west-1. Explanation: A latency routing policy directs traffic based on the lowest network latency to the specified AWS endpoint. Since the on-premises data center is near the us-west-1 Region, associating the policy with us-west-1 ensures that users near that region will be directed to the on-premises data center. This allows for optimal routing, minimizing the load time for users based on their geographical proximity to the respective hosting locations (us-west-1 and eu-central-1). Options A, B, and D do not explicitly consider latency or are not optimal for minimizing load time: Option A (geolocation routing policy) would direct traffic based on the geographic location of the user but may not necessarily optimize for the lowest latency.
Comment: There is nothing in us-west-1 as the company's data centre is near us-west-1.
Comment: except I don't think that it should be applied to the west region. If Geolocation is applied and the west is closer to the client, but the west is having intermittent issues at the time, they will have a longer latency even though closer to that region. this is why I would apply latency in a real world solution.
Comment: in real world I think it should use latency routing if the main concern is to lower the latency but AWS likes to promote geolocation and if that is in the question I think that will be the answer so I choose A.
Comment: The company wants to minimize load time for the website as much as possible… between data Centre and website or between users and website?
Comment: Geolocation is the key word
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html
Comment: The key reasons are: Geolocation routing allows you to route users to the closest endpoint based on their geographic location. This will provide the lowest latency. Routing us-west-1 traffic to the on-premises data center minimizes latency for those users since it is also located near there. Routing eu-central-1 traffic to the eu-central-1 AWS region minimizes latency for users nearby. This achieves routing users to the closest endpoint on a geographic basis to optimize for low latency.
Comment: why can't be the option C
Comment: You cannot associate the policy to us-west-1 as the AWS account is in eu-central-1
Comment: If you have made it to the end of the exam dump, you will definitely pass your exams in Jesus name. After over a year of Procrastination, I am finally ready to write my AWS Solutions Architect Exam. Thank you Exam Topics
Comment: Ready for the exam tomorrow. Wish you guys all the best. BTW Snowball Device comes in handy when you need to move a huge amount of data but cant afford any bandwidth loss
Comment: Oh, to think now we have to study 904 questions instead of just 583 lol
Comment: well, 2 weeks later today, it says 981 questions...
Comment: 5PB over 1GB connection will take approximately 15 months so anything with "transfer" is invalid. ABD are not practical. C: Just order snowball
Comment: Though we'll need more than 60 Snowball devices, C is the only option that works. The internet uplink could transport less than 2 PB in 6 months (otherwise, say with a 10 Gb uplink, D would work).
Comment: transfer 5 PB data in 1Gbps link, assume 0 overhead and drop packet, need 485 days, 10 hours, 50 minutes, 40 seconds to complete. Snowball it is. C
Comment: C https://docs.aws.amazon.com/storagegateway/latest/tgw/using-tape-gateway-snowball.html
Comment: Migrate petabyte-scale data stored on physical tapes to AWS using AWS Snowball https://aws.amazon.com/snowball/#:~:text=Migrate-,petabyte%2Dscale,-data%20stored%20on
Comment: 5 PB data is too huge for using 1Gbps uplink. With this uplink, it takes more than 1 year to migrate this data.
Comment: Answer: D for most cost effective. If you are looking for a cost-effective, durable, long-term, offsite alternative for data archiving, deploy a Tape Gateway. With its virtual tape library (VTL) interface, you can use your existing tape-based backup software infrastructure to store data on virtual tape cartridges that you create - https://docs.aws.amazon.com/storagegateway/latest/tgw/WhatIsStorageGateway.html
Comment: D https://aws.amazon.com/storagegateway/vtl/ the bandwidth and available time is ample
Comment: The most cost-effective solution to meet the requirements is to read the data from the tapes on premises. Stage the data in a local NFS storage. Use AWS DataSync to migrate the data to Amazon S3 Glacier Flexible Retrieval. This solution is the most cost-effective because it uses the least amount of bandwidth. AWS DataSync is a service that transfers data between on-premises storage and Amazon S3. It uses a variety of techniques to optimize the transfer speed and reduce c
Comment: Only thing that makes sense given the 1Gbps limitation
Comment: Option C is likely the most cost-effective solution given the large data size and limited internet bandwidth. The physical data transfer and integration with the existing tape infrastructure provides efficiency benefits that can optimize the cost.
Comment: Went through this dump twice now. Exam is in about an hour. Will update with results.
Comment: how was ur exam? was these dump que helpful?
Comment: Finished the dump today - taking my exam tomorrow :-) Wish me luck!
Comment: My rational: question is about which solution will meet these requirements MOST cost-effectively, not MOST time or effectively, then, my response is D (using Tape Gateways)
Comment: A spread placement group is a group of instances that are each placed on distinct hardware. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: C is the correct answer. Configuring the EC2 instances with dedicated tenancy ensures that each instance will run on isolated, single-tenant hardware. This meets the requirement to prevent groups of nodes from sharing underlying hardware. A spread placement group only provides isolation at the Availability Zone level. Instances could still share hardware within an AZ.
Comment: No. C ensures that your EC2 instances run on hardware that is not shared with other customers (!). It is still shared among YOUR instances.
Comment: Option A: Run the EC2 instances in a spread placement group. Spread Placement Group: This placement group strategy ensures that EC2 instances are distributed across distinct hardware to reduce the risk of correlated failures. Instances in a spread placement group are placed on different underlying hardware, which aligns with the requirement to prevent groups of nodes from sharing the same underlying hardware. This is a good fit for the scenario where you need to ensure high availability and fault tolerance.
Comment: Spread – Strictly places a small group of instances across distinct underlying hardware to reduce correlated failures.
Comment: dedicated tenancy cannot ensure the instances share the same hardware. So A
Comment: A, spread placement group does exactly what is required here. Not C and D, tenancy determines whether the hardware is shared with other customers or not, it has nothing to with your own instances sharing hardware. (On the contrary, dedicated tenancy would spread your EC2 instances across as little nodes as possible.) Not B, accounts have nothing to do with the issue.
Comment: Let's assume that you have two groups of instances, group A and group B and you have two physical hardware X and Y. With spread placement group, you can have group A of instances on hardware X and group B on hardware Y but this will not prevent hardware X to host other instances of other customers because your only requirement is to separate group A from group B. On the other hand, the dedicated tenancy means that AWS will dedicate the physical hardware only for you. So, the correct answer is A.
Comment: Question is ambiguous and confusing. Is it asking about the EC2 instance of the same application not sharing hardware? or EC2 instance not sharing hardware with other EC2 from other applications?
Comment: Spread placement group allows you to isolate your instances on hardware level. Dedicated tenancy allows you to be sure that you are the only customer on the hardware. The correct answer is A.
Comment: A : Spread placement group
Comment: Def is A: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: Keywords 'prevent groups of nodes from sharing the same underlying hardware'. Spread Placement Group strictly places a small group of instances across distinct underlying hardware to reduce correlated failures.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html Each instances is placed on seven different racks, each rack has its own network and power source.
Comment: Another tricky question, but I would go for A because: Dedicated instances: Dedicated Instances are EC2 instances that run on hardware that's dedicated to a single customer. Dedicated Instances that belong to different AWS accounts are physically isolated at a hardware level, even if those accounts are linked to a single payer account. However, Dedicated Instances might share hardware with other instances from the same AWS account that are not Dedicated Instances. Which is not the desired option. Spread – strictly places a small group of instances across distinct underlying hardware to reduce correlated failures. That's why A.
Comment: C is clear.
Comment: "Dedicated tenancy" means that all your nodes run on hardware that is not shared with other customers. This is counter-productive to the objective here.
Comment: A When you launch a new EC2 instance, the EC2 service attempts to place the instance in such a way that all of your instances are spread out across underlying hardware to minimize correlated failures. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: Spread Placement Group strictly places a small group of instances across distinct underlying hardware to reduce correlated failures.
Comment: Option A is the correct answer. It suggests running the EC2 instances in a spread placement group. This solution is cost-effective and requires minimal development effort .
Comment: The placement group reduces the risk of simultaneous failures by spreading the instances across distinct underlying hardware
Comment: Option D: Purchase a Capacity Reservation in the failover Region. Capacity Reservation: Capacity Reservations ensure that you have reserved capacity in a specific region for your instances, regardless of whether you are using On-Demand or Reserved Instances. This is ideal for DR scenarios because it guarantees that the required EC2 capacity will be available when needed.
Comment: "Business requirements state that the DR strategy must meet capacity in the failover Region" so only D meets these requirements A. No reservation of capacity B. Saving plans don't guarantee capacity C. Can be possible but it's like an active instance so doesn't really make sense
Comment: Correction on C (I mixed it up with tenancy!). Reserved instance are not really for capacity, its for type of instance which gives good discount but that is not required here.
Comment: Purchase a Capacity Reservation in the failover Region: A Capacity Reservation allows you to reserve a specific amount of EC2 instance capacity in a given region without purchasing specific instances. This reserved capacity is dedicated to your account and can be utilized for launching instances when needed. Capacity Reservations offer flexibility, allowing you to launch different instance types and sizes within the reserved capacity. Purchase regional Reserved Instances in the failover Region: Regional Reserved Instances involve paying an upfront fee to reserve a certain number of specific EC2 instances in a particular region. These reserved instances are of a predefined type and size, providing a more traditional reservation model. Regional Reserved Instances are specific to a designated region and ensure that the reserved instances of a particular specification are available when needed.
Comment: What I don't get is... can't you accomplish that by using on-demand? I understood that you can scale infinitely
Comment: It won't guarantee that you have the capacity when you need it. If available, like in most cases, it'll work. But the scenario requires a guarantee that the capacity will be available.
Comment: D Ask is to reserve capacity with RI capacity is not reserved also you can reserve capacity along with RI but only in AZ . https://repost.aws/knowledge-center/ri-reserved-capacity
Comment: Capacity Reservations mitigate against the risk of being unable to get On-Demand capacity in case there are capacity constraints. If you have strict capacity requirements, and are running business-critical workloads that require a certain level of long or short-term capacity assurance, create a Capacity Reservation to ensure that you always have access to Amazon EC2 capacity when you need it, for as long as you need it.
Comment: Capacity Reservations enable you to reserve capacity for your Amazon EC2 instances in a specific Availability Zone for any duration. This gives you the flexibility to selectively add capacity reservations and still get the Regional RI discounts for that usage. By creating Capacity Reservations, you ensure that you always have access to Amazon EC2 capacity when you need it, for as long as you need it.
Comment: Savings Plans does not provide a capacity reservation.
Comment: Capacity Reservations allocate EC2 capacity in a specific AWS Region for you to launch instances. The capacity is reserved and available to be utilized when needed, meeting the requirement to provide EC2 capacity in the failover region. Other options do not reserve capacity. On-Demand provides flexible capacity but does not reserve capacity upfront. Savings Plans and Reserved Instances provide discounts but do not reserve capacity. Capacity Reservations allow defining instance attributes like instance type, platform, Availability Zone so the reserved capacity matches the production environment.
Comment: A regional Reserved Instance does not reserve capacity https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html
Comment: reserved instances for price discount. need capacity reservation.
Comment: The Reserved Instance discount applies to instance usage within the instance family, regardless of size.
Comment: "Reserved Instances are not physical instances, but rather a billing discount " https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
Comment: D https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html
Comment: An account can only join another org when it leaves the first org. A is wrong as it's not possible C that's a new account so not really a migration D The R&D department is separating from the company so you don't want the OU to join via nesting
Comment: B as exactly described here: https://repost.aws/knowledge-center/organizations-move-accounts
Comment: Option B: Invite the R&D AWS account to be part of the new organization after the R&D AWS account has left the prior organization is the appropriate approach. This option ensures that the R&D AWS account transitions smoothly from the old organization to the new one. The steps involved are: Remove the R&D AWS account from the existing organization: This is done from the existing organization's management account. Invite the R&D AWS account to join the new organization: Once the R&D account is no longer part of the previous organization, it can be invited to and accepted into the new organization.
Comment: https://aws.amazon.com/blogs/mt/migrating-accounts-between-aws-organizations-with-consolidated-billing-to-all-features/
Comment: https://repost.aws/knowledge-center/organizations-move-accounts Remove the member account from the old organization. Send an invite to the member account from the new organization. Accept the invite to the new organization from the member account.
Comment: C is better. first migrate , then delete. avoid the data lose.
Comment: What kind of "data lose" would happen when you change the account to a new organization? And why should you migrate ALL RESOURCES of the account to a new account?
Comment: C is better. first migrate , then delete. avoid the data lose.
Comment: As per this document, B is clearly the answer. https://repost.aws/knowledge-center/organizations-move-accounts#:~:text=In%20either%20case%2C-,perform%20these%20actions,-for%20each%20member
Comment: In either case, perform these actions for each member account: - Remove the member account from the old organization. - Send an invite to the member account from the new organization. - Accept the invite to the new organization from the member account. https://repost.aws/knowledge-center/organizations-move-accounts
Comment: Creating a brand new AWS account in the new organization (Option C) allows for a clean separation and migration of only the necessary resources from the old account to the new.
Comment: "A clean separation" is already existing, they have their own account. "Migration of only the necessary resources from the old account to the new" is not asked for. They have an account in an existing organization, they need their own organization, thus move the existing account to a new organisation (B), done.
Comment: When separating a business unit from an AWS Organizations structure, best practice is to: Create a new AWS account dedicated for the business unit in the new organization Migrate resources from the old account to the new account Remove the old account from the original organization This allows a clean break between the organizations and avoids any linking between them after separation.
Comment: Says who?
Comment: B https://aws.amazon.com/blogs/mt/migrating-accounts-between-aws-organizations-with-consolidated-billing-to-all-features/
Comment: account can leave current organization and then join new organization.
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
Comment: Option C: Configure an Amazon API Gateway endpoint in front of an Amazon Kinesis Data Firehose that stores the information that the company receives in an Amazon S3 bucket. Use an API Gateway Lambda authorizer to resolve authorization. This solution meets the requirements in the following ways: Handles Unpredictable Traffic: Amazon Kinesis Data Firehose can handle variable amounts of streaming data and automatically scales to accommodate sudden increases in traffic. Integration with Web Applications: Amazon API Gateway provides a RESTful API endpoint for integrating with web applications. Authorization: An API Gateway Lambda authorizer provides the necessary authorization step to secure API access. Data Storage: Amazon Kinesis Data Firehose can deliver data directly to an Amazon S3 bucket for storage, making it suitable for long-term analytics and predictions.
Comment: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
Comment: You cannot use Kinesis Data stream to store data in S3. You need Firehose for that.
Comment: Ummm. This link (Use API Gateway Lambda authorizers) helps to validate "C" as the correct answer, not "B".
Comment: B. Amazon Kinesis Data Firehose does not save anything
Comment: option C...Amazon Kinesis Data Firehose that stores the information (that the company receives) in an Amazon S3 bucket. This answer statement is worded in a complex way. It means to say that Firehose stores the data in S3 ...which company receives from API Gateway.
Comment: Configure an Amazon API Gateway endpoint in front of an Amazon Kinesis Data Firehose that stores the information that the company receives in an Amazon S3 bucket. Use an API Gateway Lambda authorizer to resolve authorization.
Comment: Using ECS just to stores the information is a overkill. So B or C then, lambda authoriser is the key word => C
Comment: https://docs.aws.amazon.com/lambda/latest/dg/services-kinesisfirehose.html
Comment: C authorizer is configured for the method. If it is, API Gateway calls the Lambda function. The Lambda function authenticates the caller by means such as the following: Calling out to an OAuth provider to get an OAuth access token
Comment: lambda authoriser seems to be logical solution.
Comment: A, B, C => cross-region $$ D => copy snapshots -> most cost-effectively.
Comment: Option D: Copy automatic snapshots to another Region every 24 hours. Explanation: This option involves copying RDS automatic snapshots to another Region. It is a straightforward way to ensure that snapshots are available in the event of a disaster. Since RDS snapshots are typically incremental and copied periodically, this solution matches the 24-hour RPO requirement effectively and is cost-effective compared to maintaining constant cross-Region replication.
Comment: Cross region data transfer is billable so think of smallest amount of data to transfer every 24 hours
Comment: Amazon RDS creates and saves automated backups of your DB instance or Multi-AZ DB cluster during the backup window of your DB instance. RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases. RDS saves the automated backups of your DB instance according to the backup retention period that you specify. If necessary, you can recover your DB instance to any point in time during the backup retention period.
Comment: most cost-effective way is just copying the snapshot (24h delta in the storage). => D
Comment: Dddddddddd
Comment: This is the most cost-effective solution because it does not require any additional AWS services. Amazon RDS automatically creates snapshots of your DB instances every hour. You can copy these snapshots to another Region every 24 hours to meet your RPO and RTO requirements. The other solutions are more expensive because they require additional AWS services. For example, AWS DMS is a more expensive service than AWS RDS.
Comment: Snapshots are always a cost-efficience way to have a DR plan.
Comment: The key points are: ElastiCache Redis provides in-memory caching that can deliver microsecond latency for session data. Redis supports replication and multi-AZ which can provide high availability for the cache. The application can be updated to store session data in ElastiCache Redis rather than locally on the web servers. If a web server fails, the user can be routed via the load balancer to another web server which can retrieve their session data from the highly available ElastiCache Redis cluster.
Comment: Option B: Use Amazon ElastiCache for Redis to store the session state. Update the application to use ElastiCache for Redis to store the session state. Explanation: Amazon ElastiCache for Redis is suitable for session state storage because Redis provides both in-memory data storage and persistence options. Redis supports features like replication, persistence, and high availability (through Redis Sentinel or clusters). This ensures that session state is preserved and available even if individual web servers fail.
Comment: As Memcached is not HA
Comment: A As cache needs to be distributed as ALB is used.
Comment: B is correct
Comment: Elastic cache is Only for RDS
Comment: Since when?
Comment: redis is correct since it provides high availability and data persistance
Comment: B is the correct answer. It suggests using Amazon ElastiCache for Redis to store the session state. Update the application to use ElastiCache for Redis to store the session state. This solution is cost-effective and requires minimal development effort.
Comment: high availability => use redis instead of Elastich memcache
Comment: queries for reports = read replica
Comment: Create a read replica of the database. Direct the queries to the read replica.
Comment: This is the most cost-effective solution because it does not require any additional AWS services. A read replica is a copy of a database that is synchronized with the primary database. You can direct the queries for the report to the read replica, which will not affect the performance of the daily workloads
Comment: Clearly the right choice, with a read replica all the queries needed for a report are done in the replica, leaving the primary on best perfomance for write
Comment: "The company needs to route incoming requests to the appropriate microservices" In Kubernetes world, this would be called an Ingress Service so it will need B https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.6/ https://kubernetes.io/docs/concepts/services-networking/ingress/
Comment: Option B: Use the AWS Load Balancer Controller to provision an Application Load Balancer (ALB). Explanation: The AWS Load Balancer Controller can provision ALBs, which operate at the application layer (Layer 7). ALBs support advanced routing capabilities such as routing based on HTTP paths or hostnames. This makes ALBs well-suited for routing requests to different microservices based on URL paths or domains. This approach integrates well with Kubernetes and is a common pattern for microservices architectures.
Comment: Not D because - even with an API gateway you'd need an ALB or ELB (so B+D would work, but D alone does not) - you would use AWS API Gateway Controller (not "Amazon API Gateway") to create the API Gateway
Comment: https://aws.amazon.com/blogs/containers/microservices-development-using-aws-controllers-for-kubernetes-ack-and-amazon-eks-blueprints/ https://aws.amazon.com/blogs/containers/integrate-amazon-api-gateway-with-amazon-eks/
Comment: ALB is cost-effectively
Comment: ALB is considered as expensive than API Gateway, particularly on higher load. If you do not need any specific functionalities of API Gateway so you must choose ALB because it will be cheaper.
Comment: ALB is considered as LESS expensive
Comment: API Gateway has a pricing model that includes a cost per API call, and depending on the volume of requests, this could potentially be more expensive than using an Application Load Balancer.
Comment: Routing requests to the appr. microserv. can easily be done with ALB and ingress. The ingress handles routing rules to the micro.serv. With answer D you wil still need ALB or NLB as can be seen in the pics of https://aws.amazon.com/blogs/containers/integrate-amazon-api-gateway-with-amazon-eks/ or https://aws.amazon.com/blogs/containers/microservices-development-using-aws-controllers-for-kubernetes-ack-and-amazon-eks-blueprints/ so that is not the most cost-effectively.
Comment: yeah, I was going with D than checked and seems that you are right to deploy API gateway you still a LB
Comment: Both ALB and API gateway can be used to route traffic to the microservices, but the question seeks the most 'cost effective' option. You are charged for each hour or partial hour that an Application Load Balancer is running, and the number of Load Balancer Capacity Units (LCU) used per hour. With Amazon API Gateway, you only pay when your APIs are in use. I say API gateway is the best option for this case.
Comment: But you still need an ALB or ELB https://aws.amazon.com/blogs/containers/microservices-development-using-aws-controllers-for-kubernetes-ack-and-amazon-eks-blueprints/ https://aws.amazon.com/blogs/containers/integrate-amazon-api-gateway-with-amazon-eks/
Comment: AWS Load Balancer Controller: The AWS Load Balancer Controller is a Kubernetes controller that makes it easy to set up an Application Load Balancer (ALB) or Network Load Balancer (NLB) for your Amazon EKS clusters. It simplifies the process of managing load balancers for applications running on EKS. Application Load Balancer (ALB): ALB is a Layer 7 load balancer that is capable of routing requests based on content, such as URL paths or hostnames. This makes it suitable for routing requests to different microservices based on specific criteria. Cost-Effectiveness: ALB is typically more cost-effective than an NLB, and it provides additional features at the application layer, which may be useful for routing requests to microservices based on specific conditions. Option D: Amazon API Gateway is designed for creating, publishing, and managing APIs. While it can integrate with Amazon EKS, it may be more feature-rich and complex than needed for simple routing to microservices within an EKS cluster.
Comment: API Gateway provides an entry point to your microservices. https://aws.amazon.com/blogs/containers/integrate-amazon-api-gateway-with-amazon-eks/
Comment: B is correct, it is a required before exposing through api gateway
Comment: B: is correct. For EKS, use application load balancer to expose microservices
Comment: Routing to ms in k8s -> Ingresses -> Ingress Controller -> AWS Load Balancer Controller https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.6/
Comment: Microservices--> API--> API GW
Comment: D. Use Amazon API Gateway to connect the requests to Amazon EKS.
Comment: API Gateway is a fully managed service that makes it easy for you to create, publish, maintain, monitor, and secure APIs at any scale. API Gateway provides an entry point to your microservices.
Comment: https://aws.amazon.com/blogs/containers/microservices-development-using-aws-controllers-for-kubernetes-ack-and-amazon-eks-blueprints/
Comment: Store images = Amazon S3 global customer base needs to be able to access these images quickly = Amazon CloudFront deny access to users from specific countries = Amazon CloudFront geographic restrictions, signed URLs
Comment: D. Use Amazon S3 to store the images. Use Amazon CloudFront to distribute the images with geographic restrictions. Provide a signed URL for each customer to access the data in CloudFront.
Comment: Correct answer is D
Comment: answer is D
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
Comment: Use Cloudfront and geographic restriction
Comment: It seems like "Multi-AZ Redis replication group" (A) and "Multi-AZ Redis cluster" (C) are different wordings for the same configuration. However, "to minimize the impact of a node failure, we recommend that your implementation use multiple nodes in each shard" - and that is mentioned only in A.
Comment: high availability at the node level = shard and Multi A-Z = region level
Comment: did client ask for improved performance, unfortunately they didn't, so C is good to have but not part of the business requirement. My answer A.
Comment: A Multi-AZ is only option. It is regional service so can use backup to replicate but can not use for failover.
Comment: Multi-AZ is only supported on Redis clusters that have more than one node in each shard (node groups). https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/AutoFailover.html#:~:text=node%20in%20each-,shard.,-Topics
Comment: C. Use a Multi-AZ Redis cluster with more than one read replica in the replication group. In summary, option C, using a Multi-AZ Redis cluster with more than one read replica, is designed to provide both node-level and AWS Region-level high availability, making it the most suitable choice for the given requirements.
Comment: the replication structure is contained within a shard (called node group in the API/CLI) which is contained within a Redis cluster A shard (in the API and CLI, a node group) is a hierarchical arrangement of nodes, each wrapped in a cluster. Shards support replication. Within a shard, one node functions as the read/write primary node. All the other nodes in a shard function as read-only replicas of the primary node.
Comment: C is correct. Not A because in replication mode, shard have multiple nodes by default. B and D not correct because that not an option
Comment: its c for me
Comment: C: Cluster mode will create multiple shards, when node level failure, request of shard that not impacted will not has any performance impact. If the issue at AZ level, spread traffic between multiple shards shall also reduce the performance degrade.
Comment: c. Option A is not ideal because it doesn't mention read replicas, and it's generally better to have read replicas for both performance and high availability. Option B mentions Redis append-only files (AOF), but AOF alone doesn't provide high availability or fault tolerance. Option D mentions Auto Scaling, but this doesn't directly address high availability at the Region level or data replication
Comment: Multi-AZ is only supported on Redis clusters that have more than one node in each shard.
Comment: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.html
Comment: Multi-AZ replication groups provide automatic failover between AZs if there is an issue with the primary AZ. This provides high availability at the region level
Comment: What about "the node level"?
Comment: Enabling ElastiCache Multi-AZ with automatic failover on your Redis cluster (in the API and CLI, replication group) improves your fault tolerance. This is true particularly in cases where your cluster's read/write primary cluster becomes unreachable or fails for any reason. Multi-AZ with automatic failover is only supported on Redis clusters that support replication
Comment: I would go with A too I would go with A, Using AOF can't protect you from all failure scenarios. For example, if a node fails due to a hardware fault in an underlying physical server, ElastiCache will provision a new node on a different server. In this case, the AOF is not available and can't be used to recover the data.
Comment: Hate to say this, but I read the two docs linked below, and I still think the answer is A. Turning on AOF helps in data persistence after failure, but it does nothing for availability unless you use Multi-AZ replica groups.
Comment: Using EC2 hibernation and Auto Scaling warm pools will help address this: Hibernation saves the in-memory state of the EC2 instance to persistent storage and shuts the instance down. When the instance is started again, the in-memory state is restored, which launches much faster than launching a new instance. Warm pools pre-initialize EC2 instances and keep them ready to fulfill requests, reducing launch time. The hibernated instances can be added to a warm pool. When auto scaling scales out during the next testing phase, it will be able to launch instances from the warm pool rapidly since they are already initialized
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html
Comment: Amazon EC2 hibernation and warm pool
Comment: If an instance or application takes a long time to bootstrap and build a memory footprint in order to become fully productive, you can use hibernation to pre-warm the instance. To pre-warm the instance, you: Launch it with hibernation enabled. Bring it to a desired state. Hibernate it so that it's ready to be resumed to the desired state whenever needed. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernate.html#:~:text=you%20can%20use-,hibernation,-to%20pre%2Dwarm
Comment: With Amazon EC2 hibernation enabled, you can maintain your EC2 instances in a "pre-warmed" state so these can get to a productive state faster.
Comment: C: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernate.html
Comment: just use hibernation option so you won't load the full EC2 Instance
Comment: Dynamic Scaling – This is yet another type of Auto Scaling in which the number of EC2 instances is changed automatically depending on the signals received. Dynamic Scaling is a good choice when there is a high volume of unpredictable traffic. https://www.developer.com/web-services/aws-auto-scaling-types-best-practices/#:~:text=Dynamic%20Scaling%20%E2%80%93%20This%20is%20yet,high%20volume%20of%20unpredictable%20traffic.
Comment: random = dynamic A: Manual is never a solution B: Predictive is not possible as it's random D: Cannot schedule random
Comment: Dynamic scaling
Comment: https://aws.amazon.com/ec2/autoscaling/faqs/
Comment: C - " sudden traffic increases on random days of the week" --> dynamic scaling
Comment: C is the best answer here. Dynamic scaling is the most cost-effective way to automatically scale the Auto Scaling group to maintain performance during random traffic spikes.
Comment: Answer is A. Aurora Serverless v2 got autoscaling, highly available and cheaper when compared to the other options.
Comment: Not B - we can auto-scale the EC2 instance, but not "the [self-managed] PostgreSQL database ON the EC2 instance" Not C - This does not mention scaling, so it would incur high cost and still it might not be able to keep up with the "unpredictable" spikes Not D - Redshift is OLAP Data Warehouse
Comment: Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Aurora where the database automatically starts up, shuts down, and scales capacity up or down based on your application's needs. This is the least costly option for unpredictable traffic.
Comment: A: "he traffic is unpredictable for subsequent monthly sales events" --> serverless
Comment: A is probably more expensive than C. Aurora is serverless and fast. But nevertheless it needs DB migration service. Not sure DMS may not be free.
Comment: C is more expensive if you think the scenario where the traffic is low. You are paying for a larger hardware but not using it. That's why I think A is correct.
Comment: A to autoscaling
Comment: Answer is A. Aurora Serverless v2 got autoscaling, highly available and cheaper when compared to the other options.
Comment: The correct answer is A
Comment: Option B: Set up a scheduled scaling to increase Lambda provisioned concurrency before employees begin to use the application each day. Explanation: Provisioned concurrency ensures that a specified number of Lambda instances are initialized and ready to handle requests. By scheduling this scaling, you can pre-warm Lambda functions before peak usage times, reducing cold start latency. This solution directly addresses the latency issue caused by cold starts.
Comment: Provisioned concurrency pre-initializes execution environments for your functions. These execution environments are prepared to respond immediately to incoming function requests at start of day.
Comment: A is wrong API Gateway throttling limit is for better throughput, not for latency
Comment: Set up a scheduled scaling to increase Lambda provisioned concurrency before employees begin to use the application each day.
Comment: Provisioned Concurrency incurs additional costs, so it is cost-efficient to use it only when necessary. For example, early in the morning when activity starts, or to handle recurring peak usage.
Comment: B option setting up a scheduled scaling to increase Lambda provisioned concurrency before employees begin to use the application each day. This solution is cost-effective and requires minimal development effort.
Comment: https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/
Comment: SQL Queries is Athena so DE are wrong and we are now dependant on S3 A to get files into S3 C Glue to convert CSV to S3 table data B irrelevant as we don't have anything to consume data from FSx in other options
Comment: My only reservation with this answer is C. CSV is technically a table and Athena can query multiple csv from S3. Glue just seems overengineering over here
Comment: A to upload the files to S3 via SMB C to convert the data from CSV format F to query with SQL Not B (we need the data in S3, not in FSx) Not D or E (we should provide the ability to run SQL queries)
Comment: SMB + use SQL commands to query the data = Amazon S3 File Gateway mode + Amazon Athena
Comment: https://aws.amazon.com/storagegateway/file/s3/#:~:text=Amazon%20S3%20File%20Gateway%20provides,Amazon%20S3%20with%20local%20caching. "Amazon S3 File Gateway provides a seamless way to connect to the cloud in order to store application data files and backup images as durable objects in Amazon S3 cloud storage. Amazon S3 File Gateway offers SMB or NFS-based access to data in Amazon S3 with local caching" => SMB and NFS is supported in Amazon S3 File Gateway => ACF
Comment: ACF 100% sure
Comment: I thought the correct answer was BCF however I have changed my mind to BCF FSx does support SMB protocol. However so does s3 file gateway which is version 2 and 3 of the SMB protocol. Hence using it with athena ACF should be correct
Comment: SMB file share- is B incorrect?
Comment: Yes because "FSx File Gateway" uploads the files to FSx, but we need it in S3.
Comment: BCF is the correct
Comment: No because FSx File Gateway (B) uploads it to FSx while we we need it in S3. S3 File Gateway provides access to S3 via SMB.
Comment: https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format-csv-home.html https://aws.amazon.com/blogs/aws/amazon-athena-interactive-sql-queries-for-data-in-amazon-s3/ https://aws.amazon.com/storagegateway/faqs/
Comment: It should be ACF
Comment: ACF use S3 File Gateway, Use Glue and Use Athena
Comment: From https://docs.aws.amazon.com/whitepapers/latest/aws-outposts-high-availability-design/aws-outposts-high-availability-design.html With Outposts, you are responsible for providing resilient power and network connectivity to the Outpost racks to meet your availability requirements for workloads running on Outposts. You are responsible for the physical security and access controls of the data center environment. You must provide sufficient power, space, and cooling to keep the Outpost operational and network connections to connect the Outpost back to the Region. Since Outpost capacity is finite and determined by the size and number of racks AWS installs at your site, you must decide how much EC2, EBS, and S3 on Outposts capacity you need to run your initial workloads, accommodate future growth, and to provide extra capacity to mitigate server failures and maintenance events.
Comment: My exam is tomorrow. thank you all for the answers and links.
Comment: "Physical maintenance" such as replacing faulty disks is NOT your responsibility.
Comment: The activities that are the responsibility of the company's operational team when using Amazon Elastic Container Service (Amazon ECS) clusters and Amazon RDS DB instances on AWS Outposts are: Providing resilient power and network connectivity to the Outposts racks. Physical security and access controls of the data center environment. Physical maintenance of Outposts components. The solutions architect is responsible for the following activities: Managing the virtualization hypervisor, storage systems, and the AWS services that run on Outposts. Ensuring the availability of the Outposts infrastructure, including the power supplies, servers, and networking equipment within the Outposts racks. Providing extra capacity for Amazon ECS clusters to mitigate server failures and maintenance events.
Comment: F: "If there is no additional capacity on the Outpost, the instance remains in the stopped state. The Outpost owner can try to free up used capacity or request additional capacity for the Outpost so that the migration can complete." Not D: "Equipment within the Outposts rack" is AWS' responsibility, you're not supposed to touch that Not E: "When the AWS installation team arrives on site, they will replace the unhealthy hosts, switches, or rack elements"
Comment:
From
Comment:
and From
Comment:
From
Comment: Only A and C are correct. AWS is responsible for the hardware and software that run on AWS Outposts. This is a fully managed infrastructure service. AWS manages security patches, updates firmware, and maintains the Outpost equipment. AWS also monitors the performance, health, and metrics for your Outpost and determines whether any maintenance is required. https://docs.aws.amazon.com/outposts/latest/userguide/outpost-maintenance.html
Comment: "Choose three". You're missing F, you must order the Outposts rack with excess capacity
Comment: The role that physical companies will play is ACE.
Comment: E is wrong If there is a need to perform physical maintenance, AWS will reach out to schedule a time to visit your site. https://aws.amazon.com/outposts/rack/faqs/#:~:text=As%20AWS%20Outposts%20rack%20runs,the%20Outpost%20for%20compliance%20certification.
Comment: So is D, "equipment WITHIN the Outposts rack" is something that your Infra team should stay away from.
Comment: ACE AWS is responsible for the availability of the Outposts infrastructure including the power supplies, servers, and networking equipment within the AWS Outposts racks. AWS also manages the virtualization hypervisor, storage systems, and the AWS services that run on Outposts. https://d1.awsstatic.com/whitepapers/aws-outposts-high-availability-design-and-architecture-considerations.pdf
Comment: https://docs.aws.amazon.com/whitepapers/latest/aws-outposts-high-availability-design/aws-outposts-high-availability-design.html
Comment: I choose ACD
Comment: I think ACD is correct
Comment: You get to choose the capacity. F
Comment: A, C and D
Comment: ACD https://docs.aws.amazon.com/outposts/latest/userguide/outpost-maintenance.html
Comment: I think because of the shared responsibility model it is ACD
Comment: A and C are obviously right. D is wrong because "within the Outpost racks". Between E and F, E is wrong because (https://aws.amazon.com/outposts/rack/faqs/) says "If there is a need to perform physical maintenance, AWS will reach out to schedule a time to visit your site. AWS may replace a given module as appropriate but will not perform any host or network switch servicing on customer premises." So, choosing F.
Comment: Since the company requires the same level of performance for the new public endpoint in AWS. A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP connection to the selected target on the port specified in the listener configuration. Link; https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
Comment: TCP = NLB
Comment: B: Is wrong as ALB is not going to help with TCP traffic C: CloudFront is CDN. There is no content here D: API Gateway is for HTTP web/API stuff, not custom TCP port applicationns
Comment: NLBs handle millions of requests per second. NLBs can handle general TCP traffic.
Comment: The key reasons are: Aurora read replicas allow setting up replication from RDS PostgreSQL to Aurora PostgreSQL with minimal downtime. Once replication is set up, the read replica can be promoted to a full standalone Aurora DB cluster with little to no downtime. This approach leverages AWS's managed replication between the source RDS PostgreSQL instance and Aurora. It avoids having to manually create backups and restore data. Using DB snapshots or pg_dump backups requires manually restoring data which increases downtime and operational overhead. Data import from S3 would require exporting, uploading and then importing data which adds overhead.
Comment: B is correct as the question says least down time and data loss
Comment: "Use an RDS for PostgreSQL DB instance as the basis for a new Aurora PostgreSQL DB cluster by using an Aurora read replica. The Aurora read replica is available for migrating only within the same AWS Region and account. The Aurora read replica option minimizes downtime during a migration. You can promote the new cluster when you have zero (0) replication lag between the primary RDS instance and the Aurora read replica." https://repost.aws/knowledge-center/aurora-postgresql-migrate-from-rds
Comment: Not A: Would work but have some (though minor) downtime B: "The Aurora read replica option minimizes downtime during a migration" Not C: "If your data is stored using Amazon Simple Storage Service (Amazon S3)" ... in this case it is not Not D: "If ... you don't have downtime considerations, you can use this option" https://repost.aws/knowledge-center/aurora-postgresql-migrate-from-rds
Comment: ACD will have delta changes issue. Which means, RDS snapshot/export at 2pm, upload/import the table into Aurora, configure and populated completed by 6pm. This created a 4-hour gap of delta changes
Comment: please focus, we have RDS not Aurora, I don't know how you vote to create an Aurora read replica to migrate an RDS to Aurora.
Comment: I thought that too but B is correct: https://repost.aws/knowledge-center/aurora-postgresql-migrate-from-rds
Comment: LEAST operational overhead = read replica
Comment: A,B,C are all valid option. But B: The Aurora read replica option minimizes downtime during a migration.
Comment: B is correct guys. Lets see what we got here: C and D is not correct of course. We have to consider A and B. A: migration using a snapshot: this would, of course, introduce heavy data loss and down time B: migration using read replica: nearly no dataloss and downtime.
Comment: RDS PostgreSQL to Aurora PostgreSQL: • Option 1: DB Snapshots from RDS PostgreSQL restored as PostgreSQL Aurora DB • Option 2: Create an Aurora Read Replica from your RDS PostgreSQL, and when the replication lag is 0, promote it as its own DB cluster (can take time and cost $)
Comment: "The Aurora read replica option minimizes downtime during a migration" https://repost.aws/knowledge-center/aurora-postgresql-migrate-from-rds
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html
Comment: Answer [B] There are five options for migrating data from your existing Amazon RDS for PostgreSQL database to an Amazon Aurora PostgreSQL-Compatible DB cluster. 1-Using a snapshot 2-Using an Aurora read replica 3-Using a pg_dump utility 4-Using logical replication 5-Using a data import from Amazon S3 (2-Using an Aurora read replica) The Aurora read replica option minimizes downtime during a migration. Which is what the question demand so answer B; is the correct ; https://repost.aws/knowledge-center/aurora-postgresql-migrate-from-rds
Comment: Using ( 4 - using logical replication) RDS for PostgreSQL and Aurora PostgreSQL instance to migrate data off minimal downtime. But is not part of the option in the answer. Which makes answer B the best solution.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html
Comment: The key reasons are: AWS Backup automates backup of resources like EBS volumes. It allows defining backup policies for groups of resources. This removes the need to manually create backups for each resource. The AWS Backup API and CLI allow programmatic control of backup plans and restores. This enables restoring hundreds of EC2 instances programmatically after a disaster instead of manually. AWS Backup handles cleanup of old backups based on policies to minimize storage costs.
Comment: LEAST amount of effort = AWS Backup
Comment: for the question, I would choose C as well, AWS Backup of the EC2, but design, why would anything of importance be on the Ec2 that would need to be restored? Shouldn't any critical or important data be on the EBS volumes in this example or similar location?
Comment: Going with Backup. Can restore programmatically using Backup API.
Comment: AWS Step Functions allows you to orchestrate and scale distributed processing using the Map state. The Map state can process items in a large dataset in parallel by distributing the work across multiple resources. Using the Map state in Distributed mode will automatically handle the parallel processing and scaling. Step Functions will add more workers to process the data as needed. Step Functions is serverless so there are no servers to manage. It will scale up and down automatically based on demand.
Comment: https://docs.aws.amazon.com/step-functions/latest/dg/use-dist-map-orchestrate-large-scale-parallel-workloads.html
Comment: Using step functions will be overwill from my point of view. I would use Glue, it's serverless and purposely designed for such use case
Comment: Simple - user Lambda / Complex - user Step Functions
Comment: A Map in Inline mode can support concurrency of 40 parallel branches and execution history limits of 25,000 events or approximately 6,500 state transitions in a workflow. With the Distributed mode, you can run at concurrency of up to 10,000 parallel branches. So I believe if it has to process thousands of items in parallel Distributed Mode is more appropriate
Comment: https://aws.amazon.com/blogs/aws/step-functions-distributed-map-a-serverless-solution-for-large-scale-parallel-data-processing/ https://docs.aws.amazon.com/step-functions/latest/dg/sample-dist-map-s3data-process.html
Comment: The Distributed Map has been optimized for Amazon S3.,helping you more easily iterate over objects in an S3 bucket. With the Distributed mode, you can run at concurrency of up to 10,000 parallel branches. https://aws.amazon.com/step-functions/faqs/#:~:text=A%20Map%20in%20Inline%20mode,up%20to%2010%2C000%20parallel%20branches.
Comment: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-orchestrate-large-scale-parallel-workloads.html
Comment: With Step Functions, you can orchestrate large-scale parallel workloads to perform tasks, such as on-demand processing of semi-structured data. These parallel workloads let you concurrently process large-scale data sources stored in Amazon S3. https://docs.aws.amazon.com/step-functions/latest/dg/concepts-orchestrate-large-scale-parallel-workloads.html
Comment: After going through the link I confirmed the answer is B
Comment: Large Scale + Parallel = Distributed Step Function https://docs.aws.amazon.com/step-functions/latest/dg/concepts-inline-vs-distributed-map.html
Comment: 7 Years, 5 Months, 3 Weeks, 5 Days required to transfer 10PB on 400 Mbps. Finger cross the upload don't drop or timeout on year 7.
Comment: As a data engineer, this comment made both laugh and shudder at the same time -- hits too close to home
Comment: PB = snowball
Comment: To calculate the total time required in weeks, we can use the result we obtained earlier, which was approximately 6.26 × 1 0 10 6.26×10 10 weeks. So, the total time required to transfer 10 PB of data to Amazon S3, given a 500 Mbps uplink, would be approximately 6.26 × 1 0 10 6.26×10 10 weeks. However, this is an extremely large value and not practically feasible. It's important to note that the result obtained might not accurately reflect real-world scenarios due to various factors such as network limitations, bandwidth constraints, and other practical considerations. Additionally, this calculation assumes a constant transfer rate and does not consider potential optimizations or parallelization techniques that could be employed to expedite the data transfer process.
Comment: 10PB on 80% of 500Mbps (Megabits not Megabytes) will take 6.5 years. But for the sake of exam when you cannot use calculators etc, just use snowball for petabytes of transfer if it is an option!
Comment: Answer is D! not A! Fiddly fingers!
Comment: D, but even if you do not know, all 3 option (A,B and C) have the same nature ( transfer via bandwidth ) and we know that there is only one correct answer => D.
Comment: snowball for sure
Comment: 1Gbps will roughly do 7 TB in 24 hours. This means 400Mbps will only do 3x42TB.
Comment: D 1Gbps will roughly do 7 TB in 24 hours. This means 400Mbps will only do 3x42TB.
Comment: D 1Gbps will roughly do 7 TB in 24 hours. This means 400Mbps will only do 3x42TB.
Comment: D 1Gbps will roughly do 7 TB in 24 hours. This means 400Mbps will only do 3x42TB.
Comment: D. Order multiple AWS Snowball devices. Copy the data to the devices. Send the devices to AWS to copy the data to Amazon S3.
Comment: 10 PB = It's Snowballs.
Comment: Answer is DDDDD
Comment: The key reasons are: The Storage Gateway volume gateway provides iSCSI block storage using cached volumes. This allows replacing the on-premises iSCSI servers with minimal changes. Cached volumes store frequently accessed data locally for low latency access, while storing less frequently accessed data in S3. This reduces the number of on-premises servers while still providing low latency access to hot data. EBS does not provide iSCSI support to replace the existing servers. S3 File Gateway is for file storage, not block storage. Stored volumes would store all data on-premises, not in S3.
Comment: Low latency = always look for cache or local storage. A: Doesn't address low latency B: Don't think this is possible CD are both low latency but D is better: https://aws.amazon.com/storagegateway/faqs/#:~:text=In%20the%20cached%20mode%2C%20your,asynchronously%20backed%20up%20to%20AWS.
Comment: low-latency access to frequently used data = cached volumes
Comment: Answer D Here is the link ; https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html
Comment: ISCI=Volume Gateway. low-latency access to frequently used data = cached volumes
Comment: "low-latency access to FREQUENTLY used data" = Cached AWS Storage Gateway volumes
Comment: An AWS Storage Gateway volume gateway is a hybrid storage solution that connects your on-premises applications to your cloud storage. It provides low-latency access to frequently used data while storing your entire dataset in the cloud. When you configure an AWS Storage Gateway volume gateway with cached volumes, the gateway stores a copy of frequently accessed data locally. This allows you to provide low-latency access to your frequently accessed data while reducing your dependency on on-premises servers.
Comment: Answer is B. C is wrong because one-zone doesn't maximize durability, it compromises it.
Comment: No, both Standard-IA and OZ-IA have SAME durability. What differs it the availability. Durability is calculated based on how many times the data is copied and made redundant, inherently by the service itself. But that redundancy can be across one building (AZ) or multiple availability zones.
Comment: I believe it's C. The following link mentions One Zone-IA offers 99.999999999% durability. Questions says nothing about HA
Comment: B Intelligent tiering will automatically transition to S3 One Zone-IA which is not needed for durability.
Comment: 'Objects also must be readily available at any time and for any length of time'…definitely option B.
Comment: B is correct
Comment: B is correct C is not correct because data must be durable. C is only for data that can be regenerated.
Comment: Durability. Available any time for any duration => B
Comment: Minimum Days for Transition to S3 Standard-IA or S3 One Zone-IA Before you transition objects to S3 Standard-IA or S3 One Zone-IA, you must store them for at least 30 days in Amazon S3. For example, you cannot create a Lifecycle rule to transition objects to the S3 Standard-IA storage class one day after you create them. Amazon S3 doesn't support this transition within the first 30 days because newer objects are often accessed more frequently or deleted sooner than is suitable for S3 Standard-IA or S3 One Zone-IA storage. Similarly, if you are transitioning noncurrent objects (in versioned buckets), you can transition only objects that are at least 30 days noncurrent to S3 Standard-IA or S3 One Zone-IA storage. https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
Comment: A S3 Glacier is most cost effective
Comment: Between A & B, this is the tie-breaker: "Objects also must be readily available at any time and for any length of time" While Glacier IS more cost effective but it won't make the objects readily available at any time for any duration.... this is only possible with IA.
Comment: B meets the requirements. No need for intelligent Tiering because of 30 days.
Comment: process and store documents as objects. S3 is known for object storage.
Comment: When using BLOB, always try to pick a solution with S3.
Comment: MOST cost-effectively = store the objects in S3, and object metadata in the existing DB.
Comment: DynamoDB's limit on the size of each record is 400KB, so D is wrong.
Comment: C. Create an Amazon S3 bucket. Update the application to store documents in the S3 bucket. Store the object metadata in the existing database.
Comment: Storing the blobs in the db is more expensive than s3 with references in the db.
Comment: WAF, you can have 100 "rule sets" per account, each with up to 10,000 IP addresses. https://docs.aws.amazon.com/waf/latest/developerguide/limits.html
Comment: Selected Answer: C AWS Lambda and DynamoDB to dynamically manage and validate incoming requests based on registered IP addresses. https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html
Comment: web services and HTTPS = WAF
Comment: B: Looks like an incomplete solution for something different C: Not workable as Lambda for IP filtering means you have already allowed the request to pass through D NACL with entries for each registered IP is not possible.
Comment: endpoint restriction by IP addresses = AWS WAF
Comment: Associate an AWS WAF web ACL with the ALB. Use IP rule sets on the ALB to filter traffic. Update the IP addresses in the rule to include the registered IP addresses.
Comment: AWS WAF cannot be directly associated with a Web Application. But, can only be associated with Application Load Balancer, CloudFront and API Gateway.
Comment: Changing answer to C because of "20000" IP addresses. Use Lambda with ALB.
Comment: I will choose this answer if it is API Gateway. But I cannot figure out how to do lambda authentication on ALB. I will go A
Comment: You are right. I don't know of a way to use Lambda with ALB in this way. Answer is A.
Comment: ALB invokes Lambda function, sending the incoming data in JSON format. Lambda function performs task, returns HTTP response to ALB.
Comment: WAF seems still better
Comment: 10,000 IP addresses For the latest version of AWS WAF, see AWS WAF. If you want to allow or block web requests based on the IP addresses that the requests originate from, create one or more IP match conditions. An IP match condition lists up to 10,000 IP addresses or IP address ranges that your requests originate from.
Comment: WAF allows 100 rule sets, each with up to 10,000 IP addresses, per account.
Comment: A. Associate an AWS WAF web ACL with the ALB. Use IP rule sets on the ALB to filter traffic. Update the IP addresses in the rule to include the registered IP addresses.
Comment: WAF meets the requirements.
Comment: The key reasons are: Lake Formation data filters allow restricting access to rows or cells in data tables based on conditions. This allows preventing access to sensitive data. Data filters are implemented within Lake Formation and do not require additional coding or Lambda functions. Lambda functions to pre-process data or purge tables would require ongoing development and maintenance. IAM roles only provide user-level permissions, not row or cell level security. Data filters give granular access control over Lake Formation data with minimal configuration, avoiding complex custom code.
Comment: https://docs.aws.amazon.com/lake-formation/latest/dg/data-filters-about.html
Comment: B. Create data filters to implement row-level security and cell-level security. Explanation: Row-Level and Cell-Level Security: AWS Lake Formation provides built-in support for row-level and cell-level security. By using data filters, you can define policies that control access to specific rows and cells within your tables. This allows you to restrict access to sensitive information without needing to manually filter or remove data. Least Operational Overhead: This solution leverages built-in Lake Formation capabilities, reducing the need for additional infrastructure or custom code. Once the data filters are set up, they automatically enforce the security policies, minimizing ongoing operational overhead.
Comment: As it said “prevent access to portions of the data that contain sensitive information”, not the access to S3, so data filter is enough
Comment: Focus on the exact wordings: "to prevent access to portions of the data that contain sensitive information." Only option B restricts the platform to access sensitive data, option A restrict users to restrict access that doesn't serve the req here, C and D are talking about removing the sensitive data which is not the ask here
Comment: portions of the data that contain sensitive information = Filtered data.
Comment: A is possible but it does not secure the data properly and only provides table level access control (if any). CD are too much overhead B is exactly for this purpose and is a built-in feature of Lake formation
Comment: https://docs.aws.amazon.com/lake-formation/latest/dg/data-filters-about.html
Comment: You can create data filters based on the values of columns in a Lake Formation table. Easy. Lowest operational overhead.
Comment: The best solution to meet the requirements with the least operational overhead is to create data filters to implement row-level security and cell-level security. Data filters are a feature of Lake Formation that allow you to restrict access to data based on row and column values. This can be used to implement row-level security and cell-level security. To implement row-level security, you would create a data filter that only allows users to access rows where the values in certain columns meet certain criteria. For example, you could create a data filter that only allows users to access rows where the value in the customer_id column matches the user's own customer ID.
Comment: Gateway VPC Endpoint = no internet to access S3. Direct Connect = secure access to VPC.
Comment: Deploy a gateway VPC endpoint for Amazon S3 = so traffic between EC2 and S3 doesn't live AWS private network. Set up an AWS Direct Connect connection between the on-premises network and the VPC = servers on-premises can consume the output from ec2 instances via private connection.
Comment: No public internet != encrypted public internet (VPN) Direct connect is the only option.
Comment: A gateway VPC endpoint for Amazon S3 allows the EC2 instances within the VPC to access Amazon S3 buckets without using the public internet. The traffic between the VPC and S3 is routed within the AWS network. AWS Direct Connect establishes a private connection between the on-premises data center and AWS infrastructure, avoiding data transfer over the public internet and ensuring compliance with the specified requirements. It provides a dedicated network link with higher bandwidth options and potentially more consistent network performance than internet-based connections. Whereas Option A uses Site-to-Site VPN connection which is secure. However it typically runs over the public internet, which would not meet the company's requirement of avoiding public internet data transit.
Comment: I think the last sentence ("Servers in the company's on-premises data center will consume the output from an application that runs on the EC2 instances") refers to a different application. Purely from the wording, it does NOT seem to refer to the data 'loaded into S3 buckets so that it can be processed in the future' before. So the EC2 instances could write to S3, the on-premises servers can talk to the EC2 application, and data would not be transmitted over the public internet. Not A: There's no such thing as a "VPC endpoint for Amazon EC2 (!)" Not C: Transit Gateway is not for EC2->S3, VPN is over public internet Not D: Would address only the first part and use public Internet
Comment: Interface endpoint is a thing, the only reason A is not true is because of the presence of site-to-site vpn which is essentially accessing public internet
Comment: I would go for A, for two reasons: 1) "S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment. 2) we tryna access an output from an application hosted in e2 instances and not to access the s3 stored data so ideally we should use Interface Endpoints for the applications running in ec2.
Comment: You forgot the traffic from EC2 to S3. Without the Gateway Endpoint, that would go via public internet. 1. Deploy a gateway VPC endpoint for Amazon S3 = so traffic between EC2 and S3 doesn't live AWS private network. 2. Set up an AWS Direct Connect connection between the on-premises network and the VPC = servers on-premises can consume the output from ec2 instances via private connection.
Comment: Plus, in A you deploy a VPC endpoint "for EC2" (!) which doesn't exist
Comment: exists, check the docs, interface VPS endpoint != gateway VPC endpoint, they have different range of services
Comment: "Data must not be transmitted over the public internet", as it would with A (VPN).
Comment: I standhood answer is B, but why not A?
Comment: there's no such things a 'VPC endpoint for EC2', and it uses public Internet
Comment: https://aws.amazon.com/blogs/architecture/choosing-your-vpc-endpoint-strategy-for-amazon-s3/ According to this document, " S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment. However, if you're willing to manage a complex custom architecture, you can use proxies. In all those scenarios, where access is from resources external to VPC, S3 interface endpoints access S3 in a secure way." so, the answer is A.
Comment: A uses a VPC endpoint "for Amazon EC2", not S3. Also it uses public Internet.
Comment: interface VPC endpoint works with PrivateLink, so it can be connected to huge amount of services, and to EC2. Gateway VPC endpoint can't work for on-prem
Comment: data must not be transmitted over the public internet = gateway VPC endpoint for Amazon S3 and AWS Direct Connect connection between the on-premises network and the VPC.
Comment: Gateway VPC Endpoint = no internet to access S3. Direct Connect = secure access to VPC I agree with you @taustin2- Happy Learning all
Comment: The key reasons are: Kinesis Data Streams provides an auto-scaling stream that can handle large amounts of streaming data ingestion and throughput. This removes the bottlenecks around receiving the data. AWS Lambda can process and store the data in a scalable serverless manner, avoiding EC2 capacity limits. API Gateway adds API management capabilities but does not improve the underlying scalability of the EC2 application. SNS is for event publishing/notifications, not large scale data ingestion. ECS still relies on EC2 capacity.
Comment: A. Kinesis Data Streams = near realtime and scalable AWS Lambda functions = scalable
Comment: more scalable solution? = serverless = Amazon Kinesis Data Streams and AWS Lambda functions
Comment: Only A is pure serverless which means scale. A for sure.
Comment: For near-real time data ingest and processing, Kinesis and Lambda are most scalable choice.
Comment: The solution that will meet these requirements is to: Configure a VPC endpoint for Amazon S3 Update the S3 bucket policy to allow access from the VPC endpoint Update the application to use the new VPC endpoint The key reasons are: VPC endpoints allow private connectivity from VPCs to AWS services like S3 without using an internet gateway. The application can connect to S3 through the VPC endpoint while remaining in the private subnet, without internet access.
Comment: D. VPC endpoint = not internet, direct access from VPC to S3
Comment: https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html
Comment: Answer is D
Comment: application must not use the internet to connect to the S3 bucket = VPC endpoint
Comment: VPC Endpoint for S3.
Comment: D is the correct...https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html
Comment: VPC endpoint enables communication between VPC subnet and S3 bucket.
Comment: A VPC endpoint is a managed endpoint in your VPC that is connected to a public AWS service. It provides a private connection between your VPC and the service, and it does not require an internet gateway or a NAT device. Option A (internet gateway) would involve exposing the S3 bucket to the internet, which is not recommended for security reasons. Option B (VPN connection) would require additional setup and would still involve traffic going over the internet. Option C (NAT gateway) is used for outbound internet access from private subnets, not for accessing S3 without the internet.
Comment: EKS supports encrypting Kubernetes secrets at the cluster level using AWS KMS keys. This provides an automated way to encrypt secrets. Enabling this feature requires minimal configuration changes to the EKS cluster and no code changes. Other options like using Lambda functions or modifying the application code to encrypt secrets require additional development effort and overhead. Systems Manager Parameter Store could store encrypted parameters but does not natively integrate with EKS to encrypt Kubernetes secrets. The EKS secrets encryption feature leverages AWS KMS without the need to directly call KMS APIs from the application.
Comment: System manager: irrelevant Lambda or application: operational overhead So it will be B secret encryption
Comment: LEAST operational overhead? = Enable secrets encryption in the EKS cluster
Comment: https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-eks-adds-envelope-encryption-for-secrets-with-aws-kms/
Comment: https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-eks-adds-envelope-encryption-for-secrets-with-aws-kms/
Comment: BBBBBBB
Comment: Use KMS. Enable secrets encryption in KMS.
Comment: Enabling secrets encryption in the EKS cluster by using AWS Key Management Service (AWS KMS) is the least operationally overhead way to encrypt the sensitive information in the Kubernetes secrets object. When you enable secrets encryption in the EKS cluster, AWS KMS encrypts the secrets before they are stored in the EKS cluster. You do not need to make any changes to your container application or implement any additional Lambda functions.
Comment: The key reasons are: An Application Load Balancer (ALB) allows directing traffic to the application servers and provides access control via security groups. Security groups act as a firewall at the instance level and can control access to the application servers from the web servers. Network ACLs work at the subnet level and are less flexible for security groups for instance-level access control. VPC endpoints are used to provide private access to AWS services, not for access between EC2 instances. AWS PrivateLink provides private connectivity between VPCs, which is not required in this single VPC scenario.
Comment: A VPC endpoint is a managed endpoint in your VPC that is connected to a public AWS service. It provides a private connection between your VPC and the service, and it does not require an internet gateway or a NAT device. The other options do not meet all of the requirements: Option A: AWS PrivateLink is a service that allows you to connect your VPC to private services that are owned by AWS or by other AWS customers. It is not designed to be used to limit access to resources within the same VPC. Option C: A Network Load Balancer can be used to distribute traffic across multiple application servers, but it does not provide a way to limit access to the application servers. Option D: An Application Load Balancer can be used to distribute traffic across multiple application servers, but it does not provide a way to limit access to the application servers.
Comment: "limit access to the application servers so that only the web servers can access them" Can be done via NACL or SG A: Irrelevant as everything is inside the same VPC B: VPC endpoint are attached to VPC and if you deploy a VPC endpoint like this it will be in front of both app and web server. Language is weird here C: Potentially a good solution but NACL is allowing on web to app traffic and no response will reach to web servers as NACL have to be configured in both directions D: ALB in front of ASG will give an internal endpoint which can be secured by SG as recommended. ASG itself is not an endpoint that can be used with SG which is why we need ALB here. Hence D is correct
Comment: Deploy an Application Load Balancer with a target group that contains the application servers' Auto Scaling group. Configure the security group to allow only the web servers to access the application servers
Comment: I think B also working. but A company has Auto Scaling groups. D has strategy for Auto Scaling. D is correct
Comment: How do you want to "deploy a VPC endpoint" for a group of EC2 instances that are inside your VPC?
Comment: D is correct
Comment: Scaling group to Scaling group.
Comment: C - ALB is for Web applications only. NLB can be internal / not public
Comment: Both ALB and NLB can be internal or public. NLB works on layer 3 while ALB works on layer 7. Both ALB and NLB could help here, but C uses a network ACL that's missing the outbound traffic.
Comment: ALB with Security Group is simplest solution.
Comment: A VPC endpoint is a managed endpoint in your VPC that is connected to a public AWS service. It provides a private connection between your VPC and the service, and it does not require an internet gateway or a NAT device. The other options do not meet all of the requirements: Option A: AWS PrivateLink is a service that allows you to connect your VPC to private services that are owned by AWS or by other AWS customers. It is not designed to be used to limit access to resources within the same VPC. Option C: A Network Load Balancer can be used to distribute traffic across multiple application servers, but it does not provide a way to limit access to the application servers. Option D: An Application Load Balancer can be used to distribute traffic across multiple application servers, but it does not provide a way to limit access to the application servers.
Comment: We don't want to connect "to a public AWS service" but to EC2 instances. "An Application Load Balancer can be used to distribute traffic across multiple application servers, but it does not provide a way to limit access to the application servers" but the Security Group of the web servers does.
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html "Use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices."
Comment: 'Running the Amazon CloudWatch agent in the existing EKS cluster' is called Amazon CloudWatch Container Insights: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-metrics.html
Comment: Selected Answer: D https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html
Comment: EKS monitoring = Amazon CloudWatch Container Insights
Comment: I have worked on it. A is the right answer
Comment: But 'running the Amazon CloudWatch agent in the existing EKS cluster' is called Container Insights, thus D. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-metrics.html
Comment: Use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. Container Insights is available for Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and Kubernetes platforms on Amazon EC2. Container Insights supports collecting metrics from clusters deployed on AWS Fargate for both Amazon ECS and Amazon EKS.
Comment: https://aws.amazon.com/cloudwatch/features/
Comment: The key reasons are: CloudWatch Container Insights automatically collects metrics and logs from containers running in EKS clusters. This provides visibility into resource utilization, application performance, and microservice interactions. The metrics and logs are stored in CloudWatch Logs and CloudWatch metrics for central access. The CloudWatch console allows querying, filtering, and visualizing the metrics and logs in one centralized place.
Comment: D Amazon CloudWatch Application Insights facilitates observability for your applications and underlying AWS resources. It helps you set up the best monitors for your application resources to continuously analyze data for signs of problems with your applications.
Comment: What Cloudwatch Container Insights is for.
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html
Comment: Cloudwatch monitors applications and provides metrics. Cloudtrail is used for API activities in the account.
Comment: Amazon CloudWatch Container Insights is a service that collects, aggregates, and summarizes metrics and logs from containerized applications. It is designed to work with Amazon EKS and Kubernetes.
Comment: The key reasons are: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior. It analyzes AWS CloudTrail, VPC Flow Logs, and DNS logs. GuardDuty can detect threats like instance or S3 bucket compromise, malicious IP addresses, or unusual API calls. Findings can be sent to AWS Security Hub which provides a centralized security dashboard and alerts. Amazon Macie and Amazon Inspector do not monitor the breadth of activity that GuardDuty does. They focus more on data security and application vulnerabilities respectively. AWS Config monitors for resource configuration changes, not malicious activity.
Comment: - Amazon Inspector = automated vulnerability management service - Amazon GuardDuty = threat detection service that monitors for malicious activity and anomalous behavior to protect AWS accounts, workloads, and data.
Comment: “ continuously monitors for malicious activity in the AWS account, workloads, and access patterns to the S3 bucket” only guard duty for this purpose in the options
Comment: Amazon Inspector provides you with security assessments of your applications settings and configurations on your EC2 instances while Amazon GuardDuty helps with analyzing your entire AWS environment for potential threats. AWS Security Hub is a cloud security posture management service that aggregates alerts, and enables automated remediation.
Comment: Guardduty
Comment: What Guard Duty is for.
Comment: The key reasons are: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior. It analyzes AWS CloudTrail, VPC Flow Logs, and DNS logs. GuardDuty can detect threats like instance or S3 bucket compromise, malicious IP addresses, or unusual API calls. Findings can be sent to AWS Security Hub which provides a centralized security dashboard and alerts. Amazon Macie and Amazon Inspector do not monitor the breadth of activity that GuardDuty does. They focus more on data security and application vulnerabilities respectively. AWS Config monitors for resource configuration changes, not malicious activity.
Comment: Answer is C.
Comment: C is the correct. https://aws.amazon.com/guardduty/
Comment: Answer is C Since Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, Amazon Elastic Compute Cloud (EC2) workloads, container applications, Amazon Aurora databases, and data stored in Amazon Simple Storage Service (S3).
Comment: Gaurd duty is a threat detection service for accounts and workloads.
Comment: Amazon EFS provides a scalable, high performance NFS file system that can be accessed from multiple resources in AWS. AWS DataSync can perform the migration from the on-prem NFS server to EFS without interruption to existing services. This avoids having to manually move the data which could cause downtime. DataSync incrementally syncs changed data. EFS and DataSync together provide a cost-optimized approach compared to using S3 or FSx, while still meeting the requirements. Manually copying 200 GB of data to AWS would be slow and risky compared to using DataSync.
Comment: A: FSX Lustre is for parallel high performance file storage not NFS C: S3 is a blob storage, not a file system D: Too much to copy with a lot of overhead A: NFS maps to EFS and allows NFS protocol for access E: DataSync solves copy problems without interruptions
Comment: https://aws.amazon.com/compare/the-difference-between-nfs-smb/
Comment: NFS file system = EFS, Use DataSync for the migration with NFS support.
Comment: EFS can be accessed by multiple AWS resources. Datasync allowes NFS migrations.
Comment: Need to use Compliance Mode, so it's either A or C. RPO leads to Multi-AZ so C.
Comment: Agree Compliance Mode with Multi-AZ
Comment: high availability = multi AZ data must be retained for 5 years = compliance mode
Comment: No HA was mentioned though. But RPO leads to that, so IDK
Comment: https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
Comment: C is correct. A and C is potential answer because they mention compliance mode. But single AZ is recommended for test and development only. For production workloads, we need multi AZ, which is C
Comment: Trust me bro
Comment: Organizations + Restricts = SCP
Comment: For Organizations to restrict users in accounts, use an SCP.
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Comment: C is correct but for my sanity I want to know what D is talking about as it makes no sense to me. Can someone explain?
Comment: Guardrails = service control policy
Comment: C - Use SCP best way
Comment: Durable storage excludes A and B. Low-latency excludes D. Choose C.
Comment: AB are not storage or this purpose D is HDD so slow by nature C best fit
Comment: durable storage, low-latency performance = Provisioned IOPS SSD Amazon EBS volume
Comment: Provisioned IOPS SSD — Provides high performance for mission-critical, low-latency, or high-throughput workloads. Throughput Optimized HDD — A low-cost HDD designed for frequently accessed, throughput-intensive workloads.
Comment: https://aws.amazon.com/ebs/volume-types/
Comment: S3 Cross-Region Replication handles automatically copying new objects added to the source bucket to the destination bucket in a different region. It continuously replicates new photos without needing to manually copy files or set up Lambda triggers. CORS only enables cross-origin access, it does not copy objects. Using Lifecycle rules or Lambda functions requires custom code and logic to handle the copying. S3 Cross-Region Replication provides automated replication that minimizes operational overhead.
Comment: All NEW photo, not all photo. We dont want to copy existing photos
Comment: "There are two types of replication: live replication and on-demand replication. Live replication – To automatically replicate new and updated objects as they are written to the source bucket, use live replication. Live replication doesn't replicate any objects that existed in the bucket before you set up replication. To replicate objects that existed before you set up replication, use on-demand replication." https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
Comment: A does exactly that
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html To automatically replicate new objects as they are written to the bucket, use live replication, such as Cross-Region Replication (CRR). To replicate existing objects to a different bucket on demand, use S3 Batch Replication.
Comment: LEAST operational effort = Cross-Region Replication
Comment: https://aws.amazon.com/about-aws/whats-new/2015/03/amazon-s3-introduces-cross-region-replication/
Comment: S3 Cross-Region Replication is least operational overhead.
Comment: Changing answer to A,D. DynamoDB on-demand is more scalable than DynamoDB auto-scaling.
Comment: For those answering A over C, the question asks about scalability, but the text says the traffic patterns are known and don't state they will change. Both auto-scaling and on-demand can "scale", but auto-scaling is for known, on-demand is better for unknown traffic patterns. Its likely the "scalability" is more to do with the file hosting (EC2 wouldn't scale well at all vs S3)
Comment: "Most scalability" = A. Might be more expensive, but cost is irrelevant in the question.
Comment: B and D B. Deploy Amazon Aurora as the database solution. Choose the serverless DB engine mode: Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora.
Comment: on-demand capacity for DynamoDB since traffic is not consistent, and S3 & CloudFront for static files
Comment: MOST scalability - DynamoDB On-Demand > Auto Scaling + Static Content host in S3
Comment: (A) is incorrect. "On-demand capacity mode is probably best when you have new tables with unknown workloads, unpredictable application traffic." We know the workload upper limit is the total amount of subscribers & we know it's busy in the morning & not so much in the afternoon. Nothing in the question says it bursts in the morning. (C) is correct. The traffic pattern is known, so prep for the morning & the exact upper boundary is the # of subscribers.
Comment: For autoscaling we need to know the lower and upper limits. Anh the question says....application will have millions of users for 4 hours in the morning....how many millions , how much upper limit we need to set for to handle this much request? here we can't have exact estimation for the upper limit in autoscaling. Thus, better option is (A)
Comment: With autoscaling we can face throttling initially, when there is surge of requests and the load is greater than the scaling upper limit. We can gradually increase the upper limit of autoscaling and would be then able to handle the load in subsequent requests preventing ourself from using OnDemand. Thus Option (C) is more scalable as it can handle the both types of load(high & low) in efficient manner.
Comment: AD vs CD ? 1) Please read the final sentence. Which solutions will meet these requirements and provide the "MOST" scalability? 2) It is not possible to predict an exact boundary based on the number of "millions of users". So I would choose "AD".
Comment: The exact boundary is known, the application's subscribers. Leaning towards AC now.
Comment: The traffic pattern is known here.
Comment: A: On-demand scaling because the demand changes drastically (millions to thousands) D: S3 for static page is perfect B: Aurora is RDMS so not much rapid schema changes (it's subjective and DBA will argue but better options on the table are DynamoDB) E: Too much work and overhead
Comment: To be fair, 4 hours is a strange time duration for burst traffic. 20 hours of low traffic may benefit from auto-scaling's as it is long enough to be called a "depressed" traffic mode in autoscaling config. 4 hours in the morning can also be termed as "sustained period" of burst in autoscaling. This question is not theoretical, someone who has scaled Dynamo in similar scenarios will be able to answer correctly.
Comment: Question asks for "most scalability", not cost optimization. "DynamoDB auto scaling ... modifies provisioned throughput settings only when the actual workload stays elevated or depressed for a sustained period of several minutes. ... This means that provisioned capacity is probably best for you if you have relatively predictable application traffic, run applications whose traffic is consistent, and ramps up or down gradually."
Comment: "The on-demand pricing model is ideal for bursty, new, or unpredictable workloads whose traffic can spike in seconds or minutes, and when under-provisioned capacity would impact the user experience." Whereas on-demand capacity mode is probably best when you have new tables with unknown workloads, unpredictable application traffic and also if you only want to pay exactly for what you use. The on-demand pricing model is ideal for bursty, new, or unpredictable workloads whose traffic can spike in seconds or minutes, and when under-provisioned capacity would impact the user experience. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html
Comment: I understand the argument between A and C, but why not B?
Comment: "Ability to rapidly evolve their schema" -> NoSQL database, schema changes in transactional databases like RDS are difficult
Comment: Provisioned on-demand capacity: Manual: Requires manual setup and management of capacity. Cost-Effectiveness: Requires manual estimation of workload, which can result in either excess or insufficient capacity. Use Case: Suitable for relatively stable workloads with predictable capacity needs. predictable capacity needs.：4 hours in the morning,a few thousand users during the rest of the day.
Comment: Provisioned mode is more suitable and it is the default.
Comment: rapidly evolve their schema, MOST scalability for data layer = DynamoDB with on-demand capacity. on-demand capacity mode automatically enables autoscaling. MOST scalability for single page app = Amazon CloudFront distribution with the S3 bucket as the origin.
Comment: CD as pattern is known
Comment: B is valid, but not good as A
Comment: No, "ability to rapidly evolve their schema" -> Relational DB is out
Comment: SQL Injection and Cross-Site Scripting = WAF so Either B or D. Both B and D are valid options but the question doesn't indicate a real need for CloudFront, so just use WAF with the API Gateway. Answer is B.
Comment: WAF helps with layer 7 attacks like SQL injection and XSS. Shield is helpful for DDOS attacks.
Comment: WAF is good enough for SQL Injection and Cross Site scripting so A is good A: AWS Shield (basic) is not for SQL injection C: Same as A D: Good solution and will work but it provides extra DDoS protection and caching which is not needed (as we don't know much about the API also)
Comment: Question asks for protection against SQL injection and XSS, both is provided by WAF (option B). D would work too, but it would add another layer (CloudFront) with benefits that nobody asked for (and that would cost money), thus it would IMO be less 'operationally efficient'.
Comment: D. Set up API Gateway with an Amazon CloudFront distribution. Configure AWS WAF in CloudFront. Option A (Configure AWS Shield) is a DDoS protection service but doesn't specifically address SQL injection and cross-site scripting attacks. Option B (Configure AWS WAF) alone is a valid option, but integrating it with CloudFront (Option D) provides additional benefits like improved performance through caching. Option C (Set up API Gateway with CloudFront and configure AWS Shield in CloudFront) might provide DDoS protection, but for SQL injection and cross-site scripting, AWS WAF is the more appropriate service.
Comment: SQL injection and cross-site scripting attacks = AWS WAF
Comment: B or D But no need for CloudFront
Comment: AWS WAF protect agains : Presence of SQL code that is likely to be malicious (known as SQL injection). Presence of a script that is likely to be malicious (known as cross-site scripting). AWS Shield provides protection against distributed denial of service (DDoS) attacks for AWS resources, at the network and transport layers (layer 3 and 4) and the application layer (layer 7). https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
Comment: Finally, I am here at the end. Thank you guys for your support!
Comment: B. Configure AWS WAF.
Comment: B is the correct. https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-xss-conditions.html
Comment: Though you can federate Cognito with Active Directory, Cognito is for providing access to your own applications, NOT to AWS Resources.
Comment: While Amazon Cognito can integrate with Active Directory, it is more focused on providing identity management for mobile and web applications. In this scenario, where the primary concern is integrating with existing on-premises resources, using SAML-based federation with IAM roles is more appropriate.
Comment: why its not b?
Comment: Use Amazon Cognito via SAML integration. (SAML) is an open federation standard that allows an identity provider (for this case on-prem AD) to authenticate users and pass identity and security information about them to a service provider (for this case AWS). I will settle for D, because this is definitely required for this to work.
Comment: D. An Amazon Cognito user pool is a user directory for WEB and MOBILE app authentication and authorization. So it is not a best option for corporate users.
Comment: I think it is D
Comment: Access to Aws resource -> cognito, then use iam role SAML or AD -> identity pool
Comment: Cognito is for app users, to authenticate users accessing your apps. Cognito is NOT for granting access to AWS resources.
Comment: https://aws.amazon.com/identity/saml/
Comment: Geolocation routing policy — Use when you want to route traffic based on the location of users. Geo-proximity routing policy — Use when you want to route traffic based on the location of your resources and optionally switch resource traffic at one location to resources elsewhere.
Comment: "Restrict the geographic distribution of your content You can use geographic restrictions, sometimes known as geo blocking, to prevent users in specific geographic locations from accessing content that you're distributing through an Amazon CloudFront distribution." https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
Comment: "Violation to distribution rights" is something you want to handle seriously by actually blocking the access. This can only be accomplished by "OPTION A".
Comment: They're not talking about detail like your case
Comment: DNS routing can be easily bypassed, and just routing traffic from different countries to different endpoints does still not restrict what each country can see. It's clearly A.
Comment: "You can also use geolocation routing to restrict distribution of content to only the locations in which you have distribution rights" Link: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html
Comment: "Restrict the geographic distribution of your content You can use geographic restrictions, sometimes known as geo blocking, to prevent users in specific geographic locations from accessing content that you're distributing through an Amazon CloudFront distribution." https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
Comment: Actually, it also says: "You can also use geolocation routing to restrict distribution of content to only the locations in which you have distribution rights." It can be either C or A, but C seems to address the question wording better.
Comment: Check line 6 on this documentation. ...You can also use geolocation routing to restrict distribution of content to only the locations in which you have distribution rights. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html
Comment: Route 53 can only restrict for geolocation users in this case, it's not for contents. I vote for "A".
Comment: Answer is A.
Comment: I vote for A
Comment: . Configure Amazon Route 53 with a geolocation policy. By configuring Amazon Route 53 with a geolocation policy, the solutions architect can direct users to different Application Load Balancers based on their geographical location. This allows the company to serve the correct content to users in different regions without violating distribution rights. Geolocation routing policies enable you to route traffic based on the geographic location of your users, ensuring that users are directed to the nearest or most appropriate endpoint based on their location. This solution is suitable for scenarios where content distribution rights vary by region and need to be enforced accordingly.
Comment: I think it's A
Comment: WAF for filtering web traffic based on rules. In this case it may be IP address, geolocation, region. CloudFront for global distribution. B: Just balances and does not filter CD: Connects the user to the NEAREST server which is not same as AUTHORISED content
Comment: WAF for geo filtering can be configured like this: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-geo-match.html How CloudFront integrates with your WAF rules: https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html
Comment: distributions + restriction of content deleivery target = A
Comment: We want to restrict access by country. People in Spain are allowed to access certain content while people in Portugal are not. A Route 53 geolocation policy that returns the "nearest" endpoint will not help, because a) the "nearest" endpoint could be identical for multiple countries with different distribution rights and b) it could easily be bypassed.
Comment: AWS CloudFront supports geographic restrictions, also known as geo-blocking, which can be used to control the distribution of your content based on the geographic location of your viewers. You can use the CloudFront geographic restrictions feature to either grant permission to your users to access your content only if they're in one of the approved countries on your allowlist, or prevent your users from accessing your content if they're in one of the banned countries on your denylist. For example, if a request comes from a country where you are not authorized to distribute your content, you can use CloudFront geographic restrictions to block the request.
Comment: Edit: Even though you can specify DNS targets by country, this will not help.
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html
Comment: https://repost.aws/knowledge-center/cloudfront-geo-restriction
Comment: Use Geolocation routing policy to route traffic based on the location of the users.
Comment: And then? So you're routing traffic from India to a certain IP address. How will you restrict the content that they can access?
Comment: It is C
Comment: During a transfer, AWS DataSync always checks the integrity of your data. https://docs.aws.amazon.com/datasync/latest/userguide/configure-data-verification-options.html
Comment: During a transfer, AWS DataSync always checks the integrity of your data, but you can specify how and when this verification happens with the following options: Verify only the data transferred (recommended) – DataSync calculates the checksum of transferred files and metadata at the source location. https://docs.aws.amazon.com/datasync/latest/userguide/configure-data-verification-options.html
Comment: "automatically validate the integrity of the data after the transfer" -> so it should be datasync
Comment: https://aws.amazon.com/datasync/faqs/
Comment: Key requirement it "maximize availability while minimizing the operational overhead" of 200 zones to process million requests R53 is designed exactly to do this and supports zone import functionality so literally does the job of their EC2 servers but much better so BCD become "overhead" by default. I doubt D will work.
Comment: B, C and D would not "maximize availability" (not HA) and also not minimize the operational overhead.
Comment: 'maximize availability while minimizing the operational overhead' = severless = Amazon Route 53
Comment: Only A makes sense
Comment: Should be A https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html
Comment: D makes more sense to me
Comment: 1 EC2 server for millions of requests?
Comment: No, "Desired capacity 1" meaning that usually only 1 server would run, but they want to "maximize availability". And operating EC2 servers would not be "minimizing the operational overhead that is related to the management of the two servers."
Comment: S3 storage lenses can be used to find incomplete multipart uploads: https://aws.amazon.com/blogs/aws-cloud-financial-management/discovering-and-deleting-incomplete-multipart-uploads-to-lower-amazon-s3-costs/
Comment: ABD cannot do any of this so C is the right product for this use case
Comment: S3 Storage Lens provides four Cost Efficiency metrics for analyzing incomplete multipart uploads in your S3 buckets. These metrics are free of charge and automatically configured for all S3 Storage Lens dashboards. Incomplete Multipart Upload Storage Bytes – The total bytes in scope with incomplete multipart uploads % Incomplete MPU Bytes – The percentage of bytes in scope that are results of incomplete multipart uploads Incomplete Multipart Upload Object Count – The number of objects in scope that are incomplete multipart uploads % Incomplete MPU Objects – The percentage of objects in scope that are incomplete multipart uploads https://aws.amazon.com/blogs/aws-cloud-financial-management/discovering-and-deleting-incomplete-multipart-uploads-to-lower-amazon-s3-costs/
Comment: Amazon S3 Storage Lens is a cloud storage analytics solution with support for AWS Organizations to give you organization-wide visibility into object storage, with point-in-time metrics and trend lines as well as actionable recommendations.
Comment: C for sure
Comment: A blue/green deployment copies a production database environment to a separate, synchronized staging environment. You can make changes to the database in the staging environment without affecting the production environment. When you are ready, you can promote the staging environment to be the new production database environment, with downtime typically under one minute. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html
Comment: You can make changes to the RDS DB instances in the green environment without affecting production workloads. For example, you can upgrade the major or minor DB engine version, upgrade the underlying file system configuration, or change database parameters in the staging environment. You can thoroughly test changes in the green environment. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html
Comment: Option A (Create an RDS manual snapshot and upgrade) is the most straightforward and least operationally intensive method to upgrade your Amazon RDS for MySQL instance while ensuring data safety and allowing thorough testing of application functionality post-upgrade. This approach leverages RDS's snapshot capabilities to provide a reliable rollback mechanism if needed, making it the recommended choice for your scenario.
Comment: Least overhead, only CD qualify and D is actually a managed solution for what is being proposed (hopefully) in C so it's better.
Comment: C works for me
Comment: D is the answer
Comment: Relationships between entities = Graph data = Neptune
Comment: Also, Neptune Streams can monitor changes in the data and create a changelog
Comment: I come looking for one of you guys comments. Nice.
Comment: Amazon Neptune Database is a serverless graph database designed for superior scalability and availability. Neptune Database provides built-in security, continuous backups, and integrations with other AWS services. Suitable for social media. With the Neptune Streams feature, you can generate a complete sequence of change-log entries that record every change made to your graph data as it happens.
Comment: Normally Amazon Quantum Ledger Database use in blockchain DB more. So i will go for B using Neptune and Neptune Stream for relationship between entities.
Comment: Amazon QLDB tracks and maintains a sequential history of every application data change using an immutable and transparent log. It trusts the integrity of your data. Built-in cryptographic authentication provides third-party verification of data changes. QLDB ACID transactions can create accurate, event-driven systems with support for real-time streaming to Amazon Kinesis.
Comment: B Social network -> Graph Structure -> Neptune
Comment: Keyword: analyze the relationships With Amazon Neptune, you can create sophisticated, interactive graph applications that can query billions of relationships in milliseconds. https://aws.amazon.com/neptune/features/
Comment: Amazon Neptune is primarily used for managing highly connected graph data, making it well-suited for graph-based applications. In contrast, Amazon QLDB is designed for applications that require an immutable and auditable transaction history to ensure data integrity.
Comment: Exactly, thus B. "Relationships between the data entities" is "graph data".
Comment: Neptune is a graph type database and Neptune streams provides view on changes into the database: https://docs.aws.amazon.com/neptune/latest/userguide/streams.html
Comment: C is the correct answer provides a well-suited, managed, and scalable solution for storing and monitoring the database with the least operational overhead, meeting the requirements of the social media company.
Comment: AQLB is like a blockchain database. Are you sure this is the correct option for graph data?
Comment: Multiple Linux instances = Amazon Elastic File System (Amazon EFS) with multiple mount targets.
Comment: C is correct
Comment: C is correct Shared File System: Amazon EFS allows multiple Amazon EC2 instances to mount the same file system simultaneously, making it easy for multiple instances to access and modify the data concurrently.
Comment: A Multi-AZ DB instance Creates a primary DB instance with one standby DB instance in a different Availability Zone. Using a Multi-AZ DB instance provides high availability, but the standby DB instance doesn't support connections for read workloads. Therefore you will need to create a read replica from the source DB instance then serve read traffic from the read replica.
Comment: Read replica split for read traffic will distribute the overall load and improve the performance. A: Standby replica cannot serve traffic (Correct me if I am wrong here) B: Transfer Accelerator is to speed up S3 traffic. Not the case here D: Kiensis will increase concurrency but won't solve the DB performance issues
Comment: you can't read from the standby DB instance. If applications require more read capacity, you should create or add additional read replicas.
Comment: After you create a read replica from a source DB instance, the source becomes the primary DB instance. When you make updates to the primary DB instance, Amazon RDS copies them asynchronously to the read replica. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
Comment: What if other agencies don't have an aws account?
Comment: then we politely tell them "no."
Comment: A doesn't exist B is a big "hell no" D is a bad practice, even with IAM you'd use groups
Comment: Others have given reason by ABD are wrong. In case you need it, here is an AWS example exercise of understanding option C https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html
Comment: With cross-account bucket permissions Account A—can grant another AWS account, Account B, permission to access its resources such as buckets and objects. Account B can then delegate those permissions to users in its account. https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html#:~:text=4%3A%20Clean%20up-,An%20AWS%20account,-%E2%80%94for%20example%2C%20Account
Comment: C is the best answer
Comment: C may not correct as it's doesn't say if the analyst are using AWS services
Comment: in that case, an analyst user group should be created and the access should be assigned to the group. So C is better
Comment: "consulting agencies" means some companies which may have one or more analysts each. Making IAM users for each individual to manage permissions is not well-architected. You would at least create groups and assign it to users. D will work as it is possible but it won't minimize "operational efficiency"
Comment: I think it is C
Comment: This is a very rare usage scenario so here are the docs related to the product: https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/scheduled-replication.html AD: Not compatible solutions B: Either wrongly worded or missing something but if I read it correctly, it means just take a backup and restore whereas the question is about continuous replication. If B was scheduled then it would have made sense C is correct as SnapMirror is a managed solution to replicate the data
Comment: Agree, thus it said "replicated in the secondary Region" only, not create a backup infrastructure in other region for failover, i don't think we need to use Backup feature
Comment: Not A, no access with CIFS (SMB) or NFS Not B, one-time copy Not D, EFS does not offer SMB
Comment: C https://aws.amazon.com/blogs/storage/cross-region-disaster-recovery-with-amazon-fsx-for-netapp-ontap/
Comment: Amazon FSx for NetApp ONTAP supports NetApp SnapMirror, a replication technology that you can use to replicate data between two ONTAP file systems. You can configure automatic NetApp SnapMirror replication of your data to another Amazon FSx for NetApp ONTAP file system, including a file system in another AWS Region. If needed, you can fail over your applications and users to use the other Amazon FSx for NetApp ONTAP file system. With SnapMirror, you can configure replication with a Recovery Point Objective (RPO) of as low as 5 minutes, and a Recovery Time Objective (RTO) in single-digit minutes. You can configure SnapMirror using the ONTAP CLI or REST API.
Comment: SnapMirror enables you to configure replication with an RPO of as low as five minutes, and an RTO in single digit minutes. It is the recommended solution for DR when using FSx for ONTAP: https://aws.amazon.com/blogs/storage/cross-region-disaster-recovery-with-amazon-fsx-for-netapp-ontap/
Comment: You can use NetApp SnapMirror to schedule periodic replication of your FSx for ONTAP file system to or from a second file system. This capability is available for both in-Region and cross-Region deployments. https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/scheduled-replication.html
Comment: Amazon SQS is designed for event-driven and scalable message processing. It can handle large volumes of messages and automatically scales based on the incoming workload. This allows for better load distribution and scaling as compared to direct Lambda invocation.
Comment: SQS + SNS standard solution
Comment: AB are way too complicated to scale without more specifics (no idea about number of events) D SMS is not for this, it's for server migrations C SNS is notified on file creation in S3. SNS publishes to SQS which can scale according to the input load automatically. Lambda execution can scale a lot when attached to SQS. ABC have scaling limits each but C's scaling limit is much better than AB
Comment: scalable service = serverless = Amazon SQS implemented with FAN-OUT. However SQS is a pull based event distribution service, it does not trigger other services. C is the closest option.
Comment: B and C
Comment: Scalable, unpredictable request patterns = AWS Lambda Scalable, key-value data = Amazon DynamoDB
Comment: Auto Scaling cannot handle "suddenly from 0 requests to over 500 per second", use Lambda and Dynamo which for Key-value pair.
Comment: Why not AC? Size of the data has unpredictable future growth and Lambda may not be able to handle it.
Comment: Unpredictable scaling of API load = Lambda + SPI Gateway Unpredictable growth of key/value DB = DynamoDB Fargate behind API requires EKS/ECS setup which is not suitable for 0-500 varying load. Same with EC2 autoscaling. Aurora MySQL is not ideal for key/value and is better suited for relational databases
Comment: why not Fargate?
Comment: AWS Transfer Family (Option D) By configuring AWS Transfer Family SFTP endpoints, you can provide a secure and convenient way for employees to access and transfer data to and from the S3 bucket. Using custom identity provider options allows you to integrate with existing identity systems, and AWS Secrets Manager can be used to manage user credentials securely. A suggests using an AWS Lambda function to create an S3 presigned URL. While this can work, it involves manual generation of URLs and sharing them, which may not be as scalable or user-friendly. B suggests creating an IAM user for each employee with IAM policies for S3 access. This involves more operational overhead, as managing IAM users for each employee can be cumbersome and less scalable. C suggests using an S3 File Gateway. While this can work, it introduces additional components and may not be as straightforward or as efficient as using AWS Transfer Family for SFTP access.
Comment: "Use AWS Secrets Manager to manage the user credentials", so manage separate credentials for every user in Secrets Manager? And "instruct employees to use Transfer Family", actually Transfer Family is the server component, employees would use an SFTP client.
Comment: https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_FTPlong.html
Comment: Not A - S3 presigned URLs are temporary (max. 7 days); you'd need to create a new URL at least every 7 days and "instruct employees" to use it. Definitely NOT 'minimizing operational overhead'. Not B - "Instruct employees to use the AWS Management Console", using Management console to up- and download files is complex Not D - Secrets Manager is not for managing user credentials, and employees would not "use Transfer Family", they would use an (S)FTP client to access the files. C grants simple access for up/downloading, no operational overhead.
Comment: Agree, Use an AWS Lambda function to create an S3 presigned URL for 7 days limits, create URL every 7 days have operational overhead more than use Secret Manager
Comment: Glad that someone else also sees what I see in this question!
Comment: It is not operationally eficient to manage, for example, 1000 signed URLs or user credentials. In addition, it is sometimes dificult to instruct that many people. It's easier to create an S3 File Gateway and allow the users to mount it locally to access the bucket. It could be D if the answer said to use IAM roles instead of managing user credentials in Secrets Manager
Comment: but they didnt mention access in for daily use of occasional. If its occasional A works well but its permanant thing them mouting drive is solution.
Comment: i think is d
Comment: Less operational overheade is C https://docs.aws.amazon.com/filegateway/latest/files3/GettingStartedAccessFileShare.html on client pc is easily mounted. I remain with some doubts but i will go for C
Comment: i would go with A
Comment: D seems right
Comment: A. Use an AWS Lambda function to create an S3 presigned URL. This solution meets the requirements by providing a secure way for employees to access the data stored in the Amazon S3 bucket. Here's how it works: When an employee needs to access the data, they request access from the company's system. The company's system triggers an AWS Lambda function. The Lambda function generates a presigned URL with a limited validity period. The employee uses the presigned URL to access the data directly from the S3 bucket. Once the presigned URL expires, access to the data is no longer possible, enhancing security. This solution minimizes operational overhead because it leverages AWS Lambda, which is a fully managed service. There is no need to manage servers or infrastructure, and the solution provides a secure and temporary access mechanism for sharing data stored in Amazon S3.
Comment: I legitimately get worried every time we have a tie
Comment: Answer: *A* (Lambda + S3 pre-signed URL = automatic access) *You can use the pre-signed URL multiple times, up to the expiration date and time.* https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
Comment: Couldn't find any options that's good for the question. D is most operation efficient but not using AWS Secret Manager as managing credentials, should integrate with IAM or AD instead
Comment: Minimise op overhead: A: Lambdas and signed url will need to be managed and distributed to each employee every 7 days. So need database of employees and connect to lambda etc B: Too much work (imagine doing that for large number of employees!) D: Incomplete solution. SFTP endpoints need SFTP client and credential approach in Secrets Manager is not going to work
Comment: C: is correct as File Gateway can be mounted on each employee's machine as a network share. Think of it as a network drive on employee's laptop.
Comment: secure and stable connection
Comment: "Use AWS Secrets Manager to manage the user credentials Instruct employees to use Transfer Family." This is a lot of operational overhead
Comment: i would go with A, storing secret for each employ does not seem to me as minimizing operational overhead...
Comment: Creating new presigned URLs every 7 days and instructing users to use them is a lot of operational overhead.
Comment: questions earlier can generate (lambda) presigned URL/cookies to customers who pay the subscription, or decouple image uploading from social media users. i dont see why Lambda+S3 presigned URL dont work with employees around the world here. Answer A.
Comment: Because presigned URLs are temporary. Customer logs in -> get presigned URL -> can download data. This is a different use case than your own employees who need permanent access.
Comment: it's A! This is the most efficient and secure way to share data with employees. It eliminates the need for employees to create their own AWS accounts or manage their own access credentials. It also provides a centralized way to manage the data, so the company can ensure that the data is always up-to-date and secure.
Comment: No. Presigned URL = temporary, employee = permanent. Also, single presigned URL for all employees is not secure (everyone uses same URL).
Comment: "favor one EC2 instance" it is because you enable the sticky session feature, so you have to disable it
Comment: Answer: *A* Enabling stickiness may bring imbalance to the load over the backend EC2 instances since sticky sessions help the same client to always redirect to the same instance behind a load balancer.
Comment: The question is too vague. Doesn't say much about the application or EC2 instance setup. So: If you assume that application uses session management then A is correct. If you think application is crashing then D is correct for health checks If you don't assume anything about the application then B is also correct SMH, I'll go with B... happy to discuss
Comment: I'm not entirely happy with any choice but since others have chosen A, I'm just throwing B for discussion.
Comment: what about c? it actually helps distribute traffic equally across instances in all enabled AZs.
Comment: nope, if the sticky season is on, no matter how many instances you have in AZ or region, it will only send traffic to you favor session
Comment: it's A!! Session affinity is a feature of the Application Load Balancer that keeps client requests on the same EC2 instance for the duration of the session. This can cause latency issues if one EC2 instance is overloaded while others are not, as the overloaded instance will handle all subsequent requests until it is taken offline. To resolve this issue, the solutions architect should disable session affinity on the ALB. This can be done by setting the "Session affinity" parameter to "Off" in the ALB's configuration. Disabling session affinity will cause the ALB to distribute requests across all EC2 instances in the target group, rather than keeping them on a single instance. This will help to balance the load and reduce latency for all requests.
Comment: I agree with A but it assumes that ALB has session affinity enabled and app doesn't require it. What if the EC2 instances are running an application that requires session affinity? I think the question is missing some important context
Comment: Disable session affinity (sticky sessions) on the ALB
Comment: A https://repost.aws/knowledge-center/elb-fix-unequal-traffic-routing
Comment: The same article says to check health of instances. This makes D as a good candidate too. "Available healthy instances aren't evenly distributed across Availability Zones."
Comment: A makes more sense than others
Comment: BE is right. The key policy has to be modified to give lambda execution role access. You can't set another resource policy as principle. So C is not right
Comment: E is wrong, AWS Lambda function can hold only one IAM role. This role is known as the execution role. What we should do is: creating an IAM policy that allows the kms:Decrypt action and attach it to the Lambda function's execution role.
Comment: B D - The combination of Option B (Grant the decrypt permission for the Lambda IAM role in the KMS key's policy) and Option D (Create a new IAM policy with the kms permission and attach the policy to the Lambda function) ensures that both the IAM role used by the Lambda function and the KMS key policy are correctly configured to allow decryption of the files. This setup meets the security requirements and ensures the Lambda function can perform its tasks without issues.
Comment: when it comes to permissions look for the "IAM ROLE" word, lambda would need a role to decrypt the s3 object, only roles can be attached to a function not policies
Comment: B. Grant the decrypt permission for the Lambda ***IAM ROLE*** in the KMS key's policy E. Create a new ***IAM ROLE*** with the kms:decrypt permission and attach the execution role to the Lambda function.
Comment: AC are resource policy, i.e. who can use lambda. https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html D: The wording is confusing so it sort of sounds as if it is correct but you cannot attach a policy to a function.
Comment: Not A and C because they are about function's "resource policy" which controls who can manage the function, NOT what the function can do. Not D because you attach an IAM policy to an IAM principal, not to a Lambda function.
Comment: Create a new IAM role with the kms:decrypt permission and attach the execution role to the Lambda function then grant the decrypt permission for the Lambda IAM role in the KMS key's policy
Comment: CE is right
Comment: No, the "Lambda resource policy" is about who can manage the Lambda function
Comment: DE? Create an IAM role for the Lambda function that also grants decryption permission to the S3 bucket. Configure the IAM role as the Lambda functions execution role. To use an IAM policy to control access to a KMS key, the key policy for the KMS key must give the account permission to use IAM policies. https://repost.aws/knowledge-center/lambda-execution-role-s3-bucket https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html
Comment: change to CE C. Grant the decrypt permission for the Lambda resource policy in the KMS key's policy. E. Create a new IAM role with the kms:decrypt permission and attach the execution role to the Lambda function. https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html
Comment: C is about the "Lambda resource policy", who can manage the function.
Comment: B https://aws.amazon.com/blogs/big-data/analyze-amazon-s3-storage-costs-using-aws-cost-and-usage-reports-amazon-s3-inventory-and-amazon-athena/
Comment: Scalable and cost-effective way = Enable Cost and Usage Reports in the management account. Deliver the reports to Amazon S3 Use Amazon Athena for analysis
Comment: B once a month
Comment: https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html
Comment: UDP packets can scale out and in
Comment: UDP can only be monitored by NLB. ALB is for application layer (HTTP etc) R53 is DNS NAT is for port forwarding/address translation etc which is not going to help with scaling A is correct
Comment: UDP packets = Network Load Balancer
Comment: standard SQL + analyze traffic
Comment: Scalable + "The solution must support queries with standard SQL" = A B not scalable C OpenSearch is like ElasticSearch so does not support SQL syntax D EMR is processing not storage. Map-Reduce can use SQL like syntax but this option does not solve scalable storage issues. You normally run EMR on some stored data
Comment: OpenSearch can support SQL queries, https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sql-support.html
Comment: Difficult question because both A and C meet the requirements. (OpenSearch does "support queries with standard SQL".) Still, native S3 storage is slightly cheaper than storage for OpenSearch. Also, Athena does not incur additional cost while OpenSearch does. Question asks for cost efficiency, thus A. D is out, not only because of the cost but also because you do not 'store logs in (!) an Amazon EMR cluster'; you can use (!) an EMR cluster to analyze data that is stored elsewhere.
Comment: And descriptions of both products, Athena as well as OpenSearch, state that you can use them to "analyze" data.
Comment: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html
Comment: Seems that even cold storage is still more expensive than S3.
Comment: solution must support queries with standard SQL = Amazon S3 with Athena
Comment: A, most cost effective
Comment: option D (using Amazon EMR with an open-source framework) may be overkill for the relatively simple SQL-based analysis.
Comment: B is private certificate so won't help as that is for internal use C is for apex domain only and won't help with wildcard domain A is correct DE are both doable as per these articles D: https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html E: https://docs.aws.amazon.com/acm/latest/userguide/domain-ownership-validation.html D is less applicable because it does not say if R53 is being used for DNS. You only validate ownership to R53 C makes more sense as it applies to both R53 and other DNS providers
Comment: Validate domain ownership for the domain by adding the required DNS records to the DNS provider then use the AWS Certificate Manager (ACM) console to request a public certificate for the apex top domain example com and a wildcard certificate for *.example.com
Comment: AE correct
Comment: BCD are wrong
Comment: Why E and not D ?
Comment: need to put A-record and CNAME in public DNS record to proof you are the legal owner of the domain name.
Comment: Keys are supposed to be managed "outside of the AWS cloud", thus A, C and D are out.
Comment: it's A. This solution is the LEAST operational overhead because it does not require the company to manage any infrastructure or software outside of the AWS Cloud. The AWS CloudHSM key store is managed by AWS, and the company can use it to store and manage its cryptographic keys without having to worry about the underlying infrastructure or software. The CloudHSM cluster is managed by AWS, and the company can use it to create and manage its cryptographic keys without having to worry about the hardware or software. the AWS CloudHSM key store can also be used for external key managers. The AWS CloudHSM key store is a managed key store that is backed by an AWS CloudHSM cluster. The AWS CloudHSM cluster is a managed service that is provided by AWS.
Comment: "The AWS CloudHSM key store is managed by AWS" which is exactly what this company does NOT want.
Comment: it's A. This solution is the LEAST operational overhead because it does not require the company to manage any infrastructure or software outside of the AWS Cloud. The AWS CloudHSM key store is managed by AWS, and the company can use it to store and manage its cryptographic keys without having to worry about the underlying infrastructure or software. The CloudHSM cluster is managed by AWS, and the company can use it to create and manage its cryptographic keys without having to worry about the hardware or software. the AWS CloudHSM key store can also be used for external key managers. The AWS CloudHSM key store is a managed key store that is backed by an AWS CloudHSM cluster. The AWS CloudHSM cluster is a managed service that is provided by AWS.
Comment: "The AWS CloudHSM key store is managed by AWS" which is exactly what this company does NOT want.
Comment: B https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
Comment: https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html#:~:text=Document%20history-,External%20key%20stores,-PDF
Comment: Answer A does not comply because aws cloudHSM is within aws Answer B is the correct answer because the company is required to use its on-premises key manager. Following https://docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html gives :An external key store is an AWS KMS custom key store backed by an external key manager outside of AWS that you own and control.(...) Answer C and D are both solutions in the aws cloud so that does not fit.
Comment: https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
Comment: Amazon FSx for Lustre is a fully managed, high-performance file system optimized for HPC workloads. It is designed to deliver sub-millisecond latencies and high throughput, making it ideal for applications that require parallel access to shared storage, such as simulations and data analytics.
Comment: host a high performance computing (HPC) workload -> FSx lustre
Comment: FSx luster for HPC
Comment: EFS could meet the latency requirement for most (!) read (!) operations, but this is not enough here. FSx for Lustre ist specifically designed for HPC.
Comment: high performance computing (HPC) workloads, shared file system= Amazon FSx for Lustre
Comment: Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover.
Comment: A - does exactly what is required Not B - Would rely on DNS caching (as it should not) Not C - CloudFront is not for VoIP Not D - ALB does not address any of the issues and would not support VoIP
Comment: automated failover across AWS Region + minimize latency -> Global Accelerator
Comment: VoIP ==> UDP ==> Global Accelerator.
Comment: AWS Global Accelerator: AWS Global Accelerator is a service that uses static IP addresses (Anycast IPs) to provide a global entry point for your applications. It routes traffic over the AWS global network to the optimal AWS endpoint based on health, geography, and routing policies. Health Checks: AWS Global Accelerator supports health checks, allowing it to route traffic only to healthy endpoints. This helps in achieving high availability and automated failover across AWS Regions.
Comment: A https://aws.amazon.com/global-accelerator/faqs/#:~:text=Global%20Accelerator%20is%20a%20good,AWS%20Shield%20for%20DDoS%20protection.
Comment: https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-benefits-of-migrating.html
Comment: Global Accelerator is the answer as it can handle both TCP and UDP
Comment: This answer should be C
Comment: CloudFront is not for VoIP (which usually uses UDP).
Comment: GP2 - • Size of the volume and IOPS are linked, max IOPS is 16,000 GP3 - Can increase IOPS up to 16,000 and throughput up to 1000 MiB/s independently GP3 is 20% cheaper than GP2
Comment: MOST cost-effective =GP3
Comment: C https://aws.amazon.com/ebs/general-purpose/
Comment: Both gp2 and gp3 can provision up to 16.000 IOPS. gp3 is cheaper than gp2.
Comment: gp2 and gp3 can provision up to 16.000 IOPS, and gp3 is cheaper than gp2
Comment: GP3 is better and cheaper than GP2
Comment: You can migrate with both A&B but option A is LEAST operational overhead/ A: https://aws.amazon.com/tutorials/move-to-managed/migrate-sql-server-to-amazon-rds/ B: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-a-microsoft-sql-server-database-to-aurora-mysql-by-using-aws-dms-and-aws-sct.html
Comment: B - Not the LEAST operational Overhead. C - It is No-Sql - Not compatible with SQL server which is SQL D - MS Sql Server to MySQL may miss out some SQL Server functionalities. A - Read replicas for RDS is easy to create and also it is Asynchronous which should not be a problem for the analytics teams as they can bear 2-3 minutes delay
Comment: A is the correct answer since RDS supports OLAP And aurora OLTP
Comment: Only Amazon RDS allows the creation of readable standby DB instances.
Comment: A is the only choice
Comment: Images cannot be lost = high availability. Transition the objects to S3 Standard-Infrequent Access (S3 Standard-IA) after 180 days, S3 Glacier Instant Retrieval after 360 days, and S3 Glacier Deep Archive after 5 years.
Comment: https://aws.amazon.com/s3/storage-classes/glacier/
Comment: "The developer needs to configure an S3 Lifecycle rule."--->One Zone-IA can't transfer to Glacier Instant Retrieval--->A is out. Check - Unsupported lifecycle transitions https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html "Images cannot be lost = high availability"--->Can't be One Zone-IA--->B is out. "the images need to be archived but must be available instantly upon request"--->Can't be "Flexible" Retrieval--->D is out. Only C is the correct answer.
Comment: A. Here's why this option is the most cost-effective: +S3 One Zone-IA (after 180 days): Offers lower storage costs compared to S3 Standard for infrequently accessed data (180 - 360 days) while maintaining good availability for retrieval. +S3 Glacier Instant Retrieval (after 360 days): Provides immediate access to archived images (360 - 5 years) at a significantly lower cost than S3 Standard storage. Retrieval costs are incurred but typically lower than keeping the data in S3 Standard. +S3 Glacier Deep Archive (after 5 years): Offers the lowest storage cost for long-term archival (beyond 5 years) with retrieval times within 12 hours, meeting the auditor access requirement and minimizing ongoing storage costs.
Comment: https://aws.amazon.com/s3/storage-classes/glacier/#:~:text=S3%20Glacier%20Flexible%20Retrieval%20delivers,year%20and%20is%20retrieved%20asynchronously. S3 Glacier Flexible Retrieval delivers low-cost storage, up to 10% lower cost than S3 Glacier Instant Retrieval. Flexible retrieval is cheaper than Instant retrieval. S3 Glacier Flexible retrieval storage class provides minutes to 12 hours retrieval of data. Which is within the required time by auditors. --> We should select flexible retrieval. The design is not caring about the high availability. The design is caring about cost. One zone-IA is cheaper than standard IA. --> We should select One Zone IA.
Comment: "The images cannot be lost during this process" is a core requirement. The design cares about data loss and 5 years is a long time and AZ failure will result in data loss.
Comment: A, B impose risk of the images being lost in case of AZ failure D does not allow instant access after 180 days
Comment: Images cannot be lost = high availability. A exposes images to risk
Comment: The images cannot be lost during this process.
Comment: "The images cannot be lost during this process" , imho this rules out S3 One zone infrequent access. S3 Glacier Instant Retrieval gives immediate access. S3 Glacier Flexible Retrieval does not give immediate access. so C.
Comment: high availability is not mentioned, thus I go for A
Comment: "The images cannot be lost during this process."
Comment: That's not HA
Comment: I'll go for A as it doesn't talk about High availability. Considering cost. I'll go for A
Comment: "The images cannot be lost during this process."
Comment: Relax man. take a break since you have made this far so far.
Comment: Rest at the end NOT in the middle -- Kobe Bryant
Comment: A transient cluster provides cost savings because it runs only during the computation time, and it provides scalability and flexibility in a cloud environment. Option C (transient cluster with On-Demand primary node and Spot core and task nodes) exposes the core nodes to Spot Instance interruptions, which may not be acceptable for a workload that cannot lose any data.
Comment: AD are long-running so don't fit in with 6 hours schedule BC are ideal for scheduled EMR activities C is wrong as running core node on Spot instance has a risk of data loss https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html B is correct because primary, core will be stable on on-demand as recommended by AWS and task can go on spot instances as task nodes are short lived by nature anyway
Comment: "Long-running cluster" = runs until you shut it down "Transient cluster" = runs until the workload is completed This runs only 6 hours each day -> transient -> B or C "Cannot lose any data while the process is running" -> Primary and core nodes cannot be Spot instances -> A or B https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-longrunning-transient.html https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html
Comment: Cannot loose data = ondemand primary + core nodes Save on costs = spot task nodes Runs for 6 hours = transient cluster
Comment: A https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html It's long running and no data loss is needed.
Comment: The link says you can lose data if you are running a transient cluster WITH ONLY Spot instances. "Long-running" = runs until you shut it down, "Transient" = Runs until the workload is completed
Comment: Option A suggests a long-running cluster, which continues to run until manually terminated. This means that even if tasks are rerouted due to Spot Instance interruptions, the cluster itself remains active, allowing the rerouted tasks to complete on other nodes. Option B suggests a transient cluster, which is terminated after all steps are completed. If the Spot Instances are interrupted and tasks are not completed, the cluster might still terminate after the steps are deemed complete, potentially leading to incomplete processing of data.
Comment: Get up Stand up
Comment: I'm not sure, but I think this question is from professional solution architect question pool. Please have a look at this one as well. https://www.examtopics.com/discussions/amazon/view/112780-exam-aws-certified-solutions-architect-professional-sap-c02/
Comment: SCPs cannot directly apply tags to resources; they can only restrict actions based on policies. They do not automatically tag resources. SCPs are also used to enforce policies across accounts but cannot look up values from an RDS database or dynamically assign tags.
Comment: The best solution that meets all the requirements is option B. Here's why: It can tag all resources created in a specific AWS account within the organization. It uses a Lambda function to look up the appropriate cost center from the RDS database, ensuring accurate tagging. The EventBridge rule reacting to CloudTrail events ensures that resources are tagged as they are created. This approach can dynamically tag each resource with the cost center ID of the user who created it.
Comment: I will vote for A
Comment: We need a solution, to automatically tag, also the existing resources. A,C, are more or less working solutions for new resources, but neither can do the tagging of existing resources. D would add a default tag instead of the specific CC.
Comment: A is right https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_tagging_abac.html
Comment: A policy cannot look up "the cost center ID of the user who created the resource", we need Lambda to do that. Thus A is out. C would work but runs on a schedule which doesn't make sense (and we would temporarily have untagged resources). D tags resources "with a default value" which is not what we want.
Comment: Please how do you account for this part of the question with option B "The solution must tag each resource with the cost center ID of the user who created the resource." ? For me this typically what SCP would handle.
Comment: That SCP won't know the cost centre. "RDS database that maps users to cost centers" Unless the solution can read the RDS, it won't work and SCP cannot be programmed to read from RDS before applying the cost centre.
Comment: Answer is A, SCP handles the assignment, no need for a Lambda function, that's unnecessary t seems like Service Control Policies (SCPs) SCPs are a policy type that you can utilize to manage permissions across accounts in your AWS Organization. Using SCPs lets you ensure that your accounts stay within your organization's access control guidelines. SCPs can be used along-side tag policies to ensure that the tags are applied at the resource creation time and remain attached to the resource.
Comment: How would an SCP look up the correct cost center in the database?
Comment: the company still maintains the RDS, nowhere was asked to drop using it, therefore we shall use a solution that takes advantages of it.
Comment: I also choose A.
Comment: SCP cannot connect to RDS where the cost centre information is stored so A won't work.
Comment: Awsgeek75 and Pentium must be the same person. They always have the same answers with contributions always on point. Great Job!
Comment: Company have Organization. A specific AWS account need to ensure all resources were tagged. Move this specific AWS account under the company OU, use SCP to enforce top down policies that every member account to adhere. Answer A.
Comment: How would an SCP look up the correct cost center in the database?
Comment: sorry, i would choose B. because it allows you to tag resources as they are created, without requiring you to move existing resources.
Comment: This solution is the best way to meet the requirements of the company. It ensures that all resources in the specific AWS account are tagged with the cost center ID of the user who created the resource. It also allows the company to easily manage and enforce compliance with its tagging policies.
Comment: How would an SCP look up the correct cost center in the database?
Comment: Create an AWS Lambda function to tag the resources after the Lambda function looks up the appropriate cost center from the RDS database. Configure an Amazon EventBridge rule that reacts to AWS CloudTrail events to invoke the Lambda function.
Comment: This solution utilizes AWS Lambda and Amazon EventBridge to automate the tagging process based on information from the RDS database and CloudTrail events. AWS Lambda Function: Create a Lambda function that can look up the cost center information from the RDS database and tag resources accordingly. Amazon EventBridge Rule: Set up an EventBridge rule to react to AWS CloudTrail events. The rule triggers the Lambda function whenever a resource is created, allowing dynamic tagging based on the cost center associated with the user in the RDS database. This solution provides automation, ensuring that resources are tagged appropriately with the cost center ID of the user who created the resource. It also allows for flexibility in updating cost center information without modifying the infrastructure.
Comment: Key requirements: HA and Managed Services Key components: PHP, Static content, Redis Elasticache AB are instantly useless for static content scaling C could work but is less managed and "configure the backend code to reference EC2 instance" makes no sense D ECS+Linux+PHP is good managed combination when used with Fargate. S3 for static is well-architected. Multi-AZ ECache for Redis is HA also. Good managed solution for all purposes.
Comment: D. ECS + Fargate Company wants to redesign the architecture = from Server to serverless, and managed by AWS .
Comment: This solution meets the requirements because it uses AWS managed solutions for hosting the static content and the PHP application. It also uses Amazon ECS to run the PHP application in a highly available and scalable manner. The solution also uses Amazon ElastiCache for Redis to handle session information, which is highly available and scalable. The solution also uses Amazon CloudFront to provide a secure and reliable way to deliver the static content to users.
Comment: Configure an Amazon CloudFront distribution with an Amazon S3 endpoint to an S3 bucket that is configured to host the static content. Configure an Application Load Balancer that targets an Amazon Elastic Container Service (Amazon ECS) service that runs AWS Fargate tasks for the PHP application. Configure the PHP application to use an Amazon ElastiCache for Redis cluster that runs in multiple Availability Zones.
Comment: CE. C. application = ALB E. WAF to endpoint
Comment: NLB and GLB cannot handle sticky sessions. It's an application level concept (Cookies) so ALB works. Elastic IP will negate sticky sessions and this combination won't work. E give proper permissions to WAF
Comment: - Make it accessible from the web + sticky session == Public ALB - Additional security == web ACL in WAF (and integrate the web ACL to the ALB)
Comment: session affinity (sticky sessions) = Application Load Balancer WAF must be applied to the endpoint for additional security = web ACL in WAF
Comment: Session Affinity = Application Load Balancer Create a public Application Load Balancer. Specify the application target group then create a web ACL in AWS WAF. Associate the web ACL with the ALB endpoint.
Comment: users request each image only once or twice a year So the answer is D
Comment: D is correct
Comment: users request each image only once or twice a year, so infrequent is enough and cheaper
Comment: "On average, users request each image only once or twice a year." S3 Infrequent Access is more than enough for this.
Comment: Say, you have 1 TB of files that you access twice a year. Yearly cost: C, S3 Standard: 276 USD for storage, free retrieval = 276 USD D, S3 Standard-IA: 138 USD for storage, 20 € for retrieval = 158 USD
Comment: Option D: Store images in Amazon S3 Standard-Infrequent Access (S3 Standard-IA). Use S3 Standard-IA to directly deliver images by using a static website. S3 Standard-IA is designed specifically for infrequently accessed data, offering lower storage costs compared to S3 Standard while still providing the necessary durability and availability.
Comment: High Availability = excluded A (EBS) cost-effective = excluded B (EFS) only once or twice a year = S3 Standard-IA, excluded C (S3 Standard, frequent access) Left D, answer
Comment: Suppose there are thousands or millions of users, each image should be recovered once or twice a year X total users... makes it more expensive than the standard class since the recovery price of Standard-IA is $0.01 per GB + price of the requests which is also more expensive too.
Comment: Not sure if you understood what IA class does. "Recovery price is 0.001 per GB", what's the issue with that if images are requested "only once or twice a year"? Say, you have 1 TB of files that you access twice a year. S3 Standard: 276 USD for storage, free retrieval = 276 USD S3 Standard-IA: 138 USD for storage, 20 € for retrieval = 158 USD
Comment: MOST cost-effectively, request each image only once or twice a year= S3 Standard-Infrequent Access
Comment: D https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html Look at table
Comment: if the images are accessed once or twice a year, then it is cheaper to use infrequent access tier
Comment: I believe the correct answer is option D, but ChatGPT mentioned option C. I didn't understand. I'm curious about the actual correct answer.
Comment: Might be the fact the a user is requesting to view a image once or twice a year but how many users are there ? :) that's why it points to C i think. I still think that the correct answer is D due to lack of information in the description
Comment: "Users request each image only once or twice per year", this refers to all users together, it does not say "EACH user". In other words, every image is accessed once or twice a year.
Comment: A managed prefix list is a set of one or more CIDR blocks. You can use prefix lists to make it easier to configure and maintain your security groups and route tables. You can create a prefix list from the IP addresses that you frequently use, and reference them as a set in security group rules and routes instead of referencing them individually. If you scale your network and need to allow traffic from another CIDR block, you can update the relevant prefix list and all security groups that use the prefix list are updated. You can also use managed prefix lists with other AWS accounts using Resource Access Manager (RAM). https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html#:~:text=A-,managed%20prefix,-list%20is%20a
Comment: I will go for B
Comment: prefix list for CIDR blocks
Comment: https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html
Comment: Such a badly worded question: "The company has multiple offices around the world. The company needs to update security group rules to allow new office CIDR ranges or to remove old CIDR ranges across the organization." Are the CIDR groups associated to offices? That will be illogical. I think it should be VPC and not offices.
Comment: Answer is B
Comment: looks like B is the answer. Reference: https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html
Comment: You talked avout smb and nfs, you talked fsx netapp ontap C is wrong because lustre is a POSIX fs
Comment: A Because HPC equivalent in AWS is EC2. Cluster placement for low-latency: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html E: ONTAP gives NFS and SMB which is required AE is correct B does not solve low latency requirements C No support for NFS and SMB D OpenZFS is not required
Comment: https://aws.amazon.com/fsx/netapp-ontap/features/ Amazon FSx for NetApp ONTAP provides access to shared file storage over all versions of the Network File System (NFS) and Server Message Block (SMB) protocols, and also supports multi-protocol access (i.e. concurrent NFS and SMB access) to the same data. As a result, you can access Amazon FSx for NetApp ONTAP from virtually any Linux, Windows, or macOS client.
Comment: I got baited into quickly going for Lustre after reading, but forgot it doesn't not support NFS/SMB.
Comment: Amazon FSx for Lustre does not support SMB. So it's A,E
Comment: A because cluster placement group means low latency, and D because OpenZFS has less latency compared to FSx for NetApp ONTAP. See https://aws.amazon.com/fsx/when-to-choose-fsx/ FSx for OpenZFS can handle SMB and NFS. Despite that for onprem NAS appliances the aws Recommended Amazon FSx file system would be FSx for NetApp ONTAP, I still choose FSx for OpenZFS for the lower latency.
Comment: LEAST latency = cluster placement group Amazon FSx for Lustre = SMB Amazon FSx for OpenZFS = NFS Amazon FSx for NetApp ONTAP = NFS, SMB, iSCSI So, answer are A and E
Comment: A becase cluster placement group means low latency. E
Comment: HPC, NFS, SMB = FSx for NetApp ONTAP file system HPC, latency-sensitive = cluster placement group
Comment: AE https://aws.amazon.com/fsx/when-to-choose-fsx/
Comment: I don't think FSx for Lustre supports SMB. At least I could not find anything in the documentation. However, FSx for ONTAP delivers NFS and SMB support.
Comment: https://aws.amazon.com/jp/fsx/lustre/features/
Comment: To meet the requirements of migrating latency-sensitive HPC workloads with multi-protocol access (NFS and SMB) to AWS with minimal latency, the following solutions would be the most appropriate: A. Deploy compute optimized EC2 instances into a cluster placement group. C. Attach the EC2 instances to an Amazon FSx for Lustre file system.
Comment: FSx for Lustre provides Lustre, not SMB and not NFS
Comment: https://aws.amazon.com/fsx/netapp-ontap/features/#:~:text=Amazon%20FSx%20for%20NetApp%20ONTAP%20provides%20access%20to%20shared%20file,access)%20to%20the%20same%20data. "Amazon FSx for NetApp ONTAP provides access to shared file storage over all versions of the Network File System (NFS) and Server Message Block (SMB) protocols, and also supports multi-protocol access (i.e. concurrent NFS and SMB access) to the same data."
Comment: Option A: A cluster placement group provides low-latency and high-bandwidth connectivity between instances. This is particularly beneficial for high-performance computing workloads that are latency-sensitive. Instances within a cluster placement group are placed in close proximity to each other within the same Availability Zone. Option C: Amazon FSx for Lustre is a high-performance file system optimized for fast access to data. It is well-suited for high-performance computing workloads. It provides low-latency access to data and supports the NFS protocol.
Comment: Thank you
Comment: FSx for Lustre is not about NFS or SMB. You will need a linux instance. First install the open-source Lustre client on that instance. Once it's installed, you can mount your file system using standard Linux commands. So C is not correct here because NFS and SMB support is required.
Comment: 90% utilization of the bandwidth = they discouraged the use of internet bandwidth for uploading, go seek for offline data seeding to AWS method
Comment: data centers don't "discouraged the use of internet bandwidth."
Comment: 50 TB of data to AWS within 2 weeks + 90% utilization already be used -> snowball
Comment: (B) is correct. Direct Connect is "A dedicated connection [is] made through a 1-Gbps, 10-Gbps, or 100-Gbps Ethernet port dedicated to a single customer." DX uses 802.1Q VLANs providing a dedicated private network connection to AWS. At 1-Gbps, transfer takes less than 5 days; at 100-Gbps it takes less than 67 minutes. Since it's a data center & not an oil rig in the middle of the Gulf of Mexico, data center should be able to get this service. (C) is incorrect "Consider Snowball Edge if you need to run computing in rugged, austere, mobile, or disconnected (or intermittently connected) environments. Also consider it for large-scale data transfers and migrations when bandwidth is not available for use of a high-speed online transfer service, such as AWS DataSync."
Comment: B > A > C > D
Comment: Assuming vpn is 1Gbps, it can still transfer 50TB with in 5days with only 10% bandwidth avaliable
Comment: A DataSync is for data B Direct connect takes longer than 2 weeks D StorageGateway is useless without more contex C is only remaining choice.
Comment: (A) The problem is not that DataSync deals with data (we have to 'transfer 50 TB of data'). The issue is with the VPC endpoint; it doesn't increase our bandwidth. DataSync task is capable fully utilizing 10-Gbps over a network link between your on-premises environment and AWS. (B) works between 67-minutes & 5 days. (C) Works but is NOT what I would recommend to a data center. (D) over VPN connection that is 90% utilized, takes more than 6 weeks.
Comment: Not memtioned network bandwidth. How we know that?
Comment: 50 TB of data to AWS within 2 weeks = Snowball Edge Storage Optimized
Comment: occur at the same time each day = predictable So, scheduled scaling policy, Answer is D. Dynamic scaling policy work for unpredictable
Comment: D. The application performs normally 2-3 hours after peak hours begin is a key! (schedule policy)
Comment: ABC won't solve the performance issues at the start of peak hours. D ensure that application is ready for use during the peak hours by scheduling an early launch
Comment: Techincally both dynamic and scheduled scaling would work but there is strict requirement for the application to work properly at the start of peak hours and no mention of cost. So scheduled scaling policy it is.
Comment: Application users report slow application performance at the start of peak hours. The company wants to ensure that the application works properly at the start of peak hours
Comment: Amazon RDS Proxy is a fully managed, highly available database proxy for Amazon Relational Database Service (RDS) that makes applications more resilient to database failures. Many applications, including those built on modern serverless architectures, can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability. With RDS Proxy, failover times for Aurora and RDS databases are reduced by up to 66%
Comment: A: DynamoDB != RDS C: Total nonsense D: Lambda for providing connection pooling sound impractical if not impossible. Would be fun to watch someone do this though... B RDS Proxy is specifically made for connection pooling.
Comment: A out because DynamoDB is a NoSQL DB B As the question is referring about DB connections so this option has the LEAST operational overhead
Comment: This option involves managing snapshots efficiently to optimize costs with minimal operational overhead. Delete all nonessential snapshots: This reduces costs by eliminating unnecessary snapshot storage. Use Amazon Data Lifecycle Manager (DLM): DLM can automate the creation and deletion of snapshots based on defined policies. This reduces operational overhead by automating snapshot management according to the company's snapshot policy requirements.
Comment: Least operational overhead for your snapshot management is https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html C will just do it once but assuming they want an ongoing solution. A: It will help with EBS size but won't fix the snapshot problems B: Same as A, nothing to do with snapshos
Comment: Q says The company wants to optimize monthly costs for its current storage usage. I think they only want to do it once?
Comment: I think "optimize monthly costs" include future monthly cost as well, so D is better than C
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html
Comment: We're asked to restrict access to both, RDS and S3, to "the ECS cluster" (not to a subnet or endpoint). Not B: Does not restrict RDS at all. Wording about S3 is unusual. Not C: Would work for S3, but would allow RDS access from whole subnet which may contain other resources besides the ECS cluster Not D: Would allow RDS access from whole subnet which may contain other resources besides the ECS cluster. Would allow S3 access from VPC endpoint which might be accessed by other resources besides the ECS cluster.
Comment: Option D is the most comprehensive solution as it leverages VPC endpoints for both Amazon RDS and Amazon S3, along with proper network-level controls to restrict access to only the necessary resources from the ECS cluster.
Comment: D only secures access to RDS and S3, it does not secure the sensitive data inside the RDS and S3.
Comment: I cannot believe how many people vote A. the questions is asking only allow ECS cluster access RDS and access to S3. 2 keys here: 1. security group is usually used to security access between RDS and ECS cluster 2. access data in S3 securely, imemdiately, we should think about S3 VPC Gateway endpoints because this secures the traffic only travel via private network. Answer A is just talking about encrpt data at rest, and that is not what the question is asking about
Comment: After reading comments changed to A. D will not protect data at rest it will only give n/w level security
Comment: According to me "The dataset contains sensitive information" is the main information that motivate the real requirement which is "The company wants to ensure that only the ECS cluster can access the data in the RDS for MySQL database and the data in the S3 bucket". So we have to take these two assertions into consideration. And knowing that, as S3 default encryption capabilities, RDS Mysql DB Instance encryption is not active by default (check this link for details https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html ), option A is the best option to meet the requirements of accessing the datasets and the assets only from ECS cluster tasks and preserve, at the same time, data confidentiality and integrity. In other words, option A is the best one to ensure the data protection at REST for S3 and RDS and only accessed by ECS cluster.
Comment: Try to chat GPT Please
Comment: A seems right
Comment: Vote for A. Keywords: “sensitive information” and “data in…” D: only network control, can't control data access on sensitive information.
Comment: I did not get how does D achieves the only access from ECS cluster to S3 VPC endpoint.
Comment: A; When Only the ECS task execution role is able to encrypt and decrypt the data in the RDS and in the S3 bucket by means of the KMS key policy, you ensure that nothing else can read or modify the data. B: this answer doesn't state that only the ECS cluster can reach the data. C: Creating a VPC endpoint for RDS does not mean that only the ECS cluster can reach the data D: The S3 VPC endpoint does not guarantee that only the ECS cluster can reach the data. Also allowing a subnet to have access to the RDS sounds too open to me
Comment: Options A and B involve using AWS Key Management Service (AWS KMS) for encryption but do not directly address the requirement to restrict access to the ECS cluster. Option C is not the most direct approach for restricting access to the RDS database, as it focuses on the S3 bucket. Therefore, option D is the most appropriate solution for ensuring that only the ECS cluster can access the data in the RDS for MySQL database and the data in the S3 bucket.
Comment: A VPC endpoint enables customers to privately connect to supported AWS services and VPC endpoint services powered by AWS PrivateLink.
Comment: C need to restrict access from ECS cluster
Comment: Create a VPC endpoint for Amazon RDS for MySQL: This ensures that the ECS cluster can access the RDS database directly within the same Virtual Private Cloud (VPC), without having to go over the internet. By updating the security group to allow access only from the specific subnets that the ECS cluster will generate tasks in, you limit access to only the authorized entities. Create a VPC endpoint for Amazon S3: This allows the ECS cluster to access the S3 bucket directly within the same VPC. By updating the S3 bucket policy to allow access only from the S3 VPC endpoint, you restrict access to the designated VPC, ensuring that only authorized resources can access the S3 bucket.
Comment: I agree this will allow only resources from VPC but will not restrict only ECS cluster. I suggest we use bucket policy to use ECS cluster role on top of network settings.
Comment: Burstable Performance Instances (T3 or T3a): These instances are designed for burstable workloads and provide a baseline level of CPU performance with the ability to burst above that baseline when needed. Bursting is particularly beneficial for handling sudden spikes in CPU utilization, such as those described in the scenario. Unlimited Mode: Enabling "unlimited" mode allows instances to burst beyond their baseline performance without accumulating CPU credits. This is important for handling sudden and sustained increases in CPU utilization during peak hours. Scale on Predictive Metrics: Configuring the environment to scale on predictive metrics allows AWS Elastic Beanstalk to proactively adjust the number of instances based on anticipated demand. This can help ensure that the environment is scaled up before the latency issues occur, addressing them in advance.
Comment: Traffic is "immediately increases". We can't predict and can not use Predictive Metrics. And requirement need auto scaling
Comment: "Scale on predictive metrics" does not sound like something that Beanstalk can do. In EC2 you can create a "predictive scaling policy", but apparently this is not supported by Beanstalk. That would rule out D. We have no indication that the application is CPU-intensive in general. If CPU utilization "increases to 10 times its normal amount" then the "normal amount" cannot be higher than 10 %. This would rule out B and C.
Comment: Explain to me why it's not B?
Comment: I have the same question.
Comment: D - No such service as Elastic Beanstalk Predictive Scaling, And even if there was, no historical data in AWS for an application we are just about to migrate to AWS. Therefore: A
Comment: D is incorrect Predictive scaling not fit
Comment: For those voting D, predictive scaling analyses historic data to predict the scaling needs. This scenario is a migration scenario so there won't be any historic data which is why D won't work. A (burst) is the only option after migration.
Comment: BC are compute optimised instances which don't solve 10x CPU issues at start of the latency. AD are burstable performance which will help with 10x increase CPU usage D is not an available feature of Elastic Beanstalk (yet) or I cannot find it in config/docs. Happy to be corrected A makes sense due to burst performance. Scale based on requests is possible and I'm assuming that latency is related to requests.
Comment: Following https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.as.html I see: " You can scale based on several statistics including latency, disk I/O, CPU utilization, and request count. " So no 'scale on predictive metrics, so D is not okay. Also, the company also wants to scale the application automatically when application demand increases, so scale on a schedule is not appropriate here. So C is not okay. Burstable performance instances in unlimited mode can sustain high CPU utilization for any period of time whenever required, so an immediate demand of CPU resources is 'covered'. So I go for A.
Comment: Option A, which suggests using burstable performance instances in unlimited mode, is appropriate. However, option D is more specific to the requirement of scaling based on predictive metrics, which is crucial for handling the latency issues that occur at specific times each month. Options B and C suggest using compute optimized instances and scaling based on requests or on a schedule. While these options might work for general scalability, they may not address the immediate and intense spikes in CPU utilization that are mentioned in the scenario. Therefore, option D is the most appropriate solution for improving latency and automatically scaling the application based on predictive metrics using AWS Elastic Beanstalk.
Comment: This solution meets the requirements because it allows the company to automatically scale the application's CPU capacity based on the number of requests it receives. The burstable performance instances provide high CPU performance when needed, which can help to reduce latency during peak hours. not D: this solution has some drawbacks. First, it can be expensive to use burstable performance instances in unlimited mode, as the instances are charged per hour. Second, it can be difficult to predict the exact CPU requirements of the application, which can lead to over- or under-provisioning of CPU resources.
Comment: The company also wants to scale the application automatically when application demand increases = Scale based on requests
Comment: B Question is asking scale based on demand so better scale based on requests. Predictive metrics not defined and may be interpreted differently by many users.
Comment: Given the scenario described, the best solution among the provided options to meet the requirements of migrating the application to AWS, improving latency, and scaling the application automatically during increased demand would be: D. Configure an Elastic Beanstalk environment to use burstable performance instances in unlimited mode. Configure the environment to scale on predictive metrics.
Comment: In this scenario, the application experiences latency issues during peak hours with a sudden increase in CPU utilization. Using burstable performance instances in unlimited mode allows the application to burst beyond the baseline performance when needed. Configuring the environment to scale on predictive metrics enables proactive scaling based on anticipated increases in demand.
Comment: use automation to secure its systems and network infrastructure = AWS CloudFormation track and audit all incremental changes to the infrastructure = AWS Config
Comment: I will go for B
Comment: Organisations is not really related to this AWS Service Catalog is like a IaaC source control so D is a close option. However B looks more logical.
Comment: The difference is in wording: "The company's security team must be able to track and audit all incremental changes to the infrastructure" If this has to be done BEFORE the deployment then D is the option If this is AFTER the deployment then B is the option Hopefully exam will have better language. Good luck!
Comment: Option B is the most suitable because it combines the benefits of infrastructure as code (CloudFormation) with tracking and auditing capabilities (AWS Config). With CloudFormation, the company can define and deploy its infrastructure in a repeatable and automated way, ensuring consistency and adherence to security standards. AWS Config then complements this by providing visibility into changes and configuration details.
Comment: To achieve high availability for the website, Migrate the database to an Amazon RDS for MySQL Multi-AZ DB instance and Create an Application Load Balancer to distribute traffic to an Auto Scaling group of EC2 instances that are distributed across two Availability Zones.
Comment: I sold my soul to the devil to pass the exam
Comment: B: RDS HA E: Application HA C: Company cannot change code so this won't work A: Does not make sense with other options D: Makes no sense with other options
Comment: A. no failed over mechanism C. DynamoDB is no SQL, cannot use with MySQL D. Not HA, just sync/replication tools. Answer BE.
Comment: Ans is C: >>You can access Amazon S3 from your VPC using gateway VPC endpoints. After you create the gateway endpoint, you can add it as a target in your route table for traffic destined from your VPC to Amazon S3. There is no additional charge for using gateway endpoints. Amazon S3 supports both gateway endpoints and interface endpoints. With a gateway endpoint, you can access Amazon S3 from your VPC, without requiring an internet gateway or NAT device for your VPC, and with no additional cost. However, gateway endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a transit gateway. For those scenarios, you must use an interface endpoint, which is available for an additional cost. For more information, see Types of VPC endpoints for Amazon S3 in the Amazon S3 User Guide. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
Comment: Gateway Endpoint -> only within same VPC Interface Endpoint -> On-premises (VPN or Direct Connect), or different Region over VPC peering.
Comment: Please C
Comment: Gateway endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a transit gateway. For those scenarios, you must use an interface endpoint, which is available for an additional cost. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html With AWS PrivateLink for Amazon S3, you can provision interface VPC endpoints (interface endpoints) in your virtual private cloud (VPC). These endpoints are directly accessible from applications that are on premises over VPN and AWS Direct Connect, or in a different AWS Region over VPC peering.
Comment: Not A, Gateway endpoint can be accessed only from inside the VPC it's in Not B, Transit Gateway alone won't help Not D, KMS has nothing to do with this
Comment: Answer seems to be C gateway endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a transit gateway. For those scenarios, you must use an interface endpoint, which is available for an additional cost. For more information, see Types of VPC endpoints for Amazon S3 in the Amazon S3 User Guide.
Comment: gateway endpoint uses public ip address even if traffic does not directly route thru the internet, also they are no meant to be used from on-premises. Answer is C
Comment: Options A, B, and D are not the most suitable for the following reasons: A. Create gateway endpoints for Amazon S3: Gateway endpoints are used for accessing S3 from within a VPC, but they do not extend connectivity to on-premises locations. B. Create a gateway in AWS Transit Gateway: AWS Transit Gateway is designed for routing traffic between VPCs and on-premises networks but is not used as a direct gateway for S3 access. D. Use an AWS Key Management Service (AWS KMS) key: AWS KMS is a key management service and does not provide direct access to S3. It's used for managing encryption keys. Therefore, option C, creating interface endpoints for Amazon S3, is the most appropriate solution for securely accessing S3 from both the AWS Region and the on-premises location.
Comment: Gateway endpoints for Amazon S3 Interface endpoints for Amazon S3 In both cases, your network traffic remains on the AWS network. Use Amazon S3 public IP addresses Use private IP addresses from your VPC to access Amazon S3 Use the same Amazon S3 DNS names Require endpoint-specific Amazon S3 DNS names Do not allow access from on premises Allow access from on premises Do not allow access from another AWS Region Allow access from a VPC in another AWS Region by using VPC peering or AWS Transit Gateway Not billed Billed
Comment: Transit Gateway support inter region. interface gateway not use in S3
Comment: com.amazonaws.ap-southeast-1.s3 amazon Interface Interface is now available for S3
Comment: GW Endpoint is only for S3 and DynamoDB, interface endpoint for other services so C is wrong
Comment: you can't access gateway endpoint from on-premises
Comment: but you can via direct connection
Comment: S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment. https://aws.amazon.com/blogs/architecture/choosing-your-vpc-endpoint-strategy-for-amazon-s3/#:~:text=associated.%20S3%20gateway-,endpoints,-do%20not%20currently
Comment: C . S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment. However, if you're willing to manage a complex custom architecture, you can use proxies. In all those scenarios, where access is from resources external to VPC, S3 interface endpoints access S3 in a secure way. https://aws.amazon.com/blogs/architecture/choosing-your-vpc-endpoint-strategy-for-amazon-s3/
Comment: Selected Answer: A https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html Gateway VPC endpoints provide reliable connectivity to Amazon S3 and DynamoDB without requiring an internet gateway or a NAT device for your VPC. There is no additional charge for using gateway endpoints.
Comment: You can't use GW endpoint from on-premises
Comment: CCCCCC
Comment: Amazon VPC interface endpoints enable you to privately connect your VPC to supported AWS services without requiring an internet gateway, NAT device, VPN, or Direct Connect connection. By creating interface endpoints for Amazon S3 in both the AWS Region and the on-premises location, you can securely access data without traversing the internet. Direct Connect Connection: With an AWS Direct Connect connection established between the AWS Region and the on-premises location, the data can flow over the dedicated, private connection rather than going over the public internet.
Comment: A: Don't think this is possible. B: Cross account role with deny policy? Never seen anything like this C: Resource groups have nothing to do with allowed tags D: Correct https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html
Comment: Other options don't make sense
Comment: A tag policy can also specify that noncompliant tagging operations on specified resource types are enforced. In other words, noncompliant tagging requests on specified resource types are prevented from completing.
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html
Comment: D https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html
Comment: password rotation = AWS Secrets Manager
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html
Comment: "Least operational overhead" A: Lambda overhead so not correct B: CLI = overhead D: Yes, it can be done but requires more work for integration. C: This is correct way of doing it. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html#rds-secrets-manager-overview
Comment: Secrets Manager allows that, least overhead
Comment: With provisioned capacity mode, you specify the number of reads and writes per second that you expect your application to require, and you are billed based on that. Furthermore if you can forecast your capacity requirements you can also reserve a portion of DynamoDB provisioned capacity and optimize your costs even further. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html
Comment: DynamoDB On-Demand pricing is about 6.94x the cost of provisioned capacity. If your applications have predictable traffic patterns and you don't mind spending the time to understand those patterns, using DynamoDB's provisioned throughput capacity can save you money. Also can't set any capacity units for on-demand mode, so A is false in it's premise. https://www.serverless.com/blog/dynamodb-on-demand-serverless
Comment: A: is most cost effective (which is a question/requirement ) - 4h per week for Tests purpose
Comment: CD are expensive as reserved capacity even with discounts would spend most time in idle mode (over paid, under utilized) A: On demand is good if you have unpredictable usage, https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.OnDemand B: Provisioned is good if you the usage: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html "The company knows how many read and write operations the application performs to the table each second during the tests." so ideally they can set this as max
Comment: I initially thought it would be A, but when they mentioned "Update the read and write capacity units appropriately." which are automatically set in "on-demand" switched to B
Comment: Provisoned Mode shoud be the answer seeing that the workloads are predictable and DynamoDB isnt used for any other thing.
Comment: On-demand mode Option A: On-demand mode is suitable for workloads that are unpredictable or that do not have significant or consistent database traffic. It automatically scales to accommodate workload demands and charges for the read and write throughput that the application consumes. For infrequent testing, this could be cost-effective because you only pay for what you use during the testing period and don't incur costs when the table is not being accessed. Whereas for the Option B, if you only run tests once a week for 4 hours, you might pay for unused capacity for the rest of the week unless you manually scale down the capacity after tests are completed, which adds operational overhead.
Comment: Agree with B, on-demand mode might not scale fast enough after the DB has been idle for 164 hours. As they know exactly the number of reads and writes per second, should use provisioned mode, and set capacity to 1 RCU and 1 WCU while the DB is not in use.
Comment: Provisioned Mode (Option B): Provisioned mode allows you to specify the desired read and write capacity units. Since the workload occurs once a week for 4 hours, you can provision the read and write capacity units accordingly to handle the expected load during that time. This can be a more cost-effective option than on-demand pricing for predictable workloads.
Comment: AWS Cost Anomaly Detection (Option B): AWS Cost Anomaly Detection is designed to automatically detect unusual spending patterns based on machine learning algorithms. It can identify anomalies and send notifications when it detects unexpected changes in spending. This aligns well with the requirement to prevent unusual spending and notify stakeholders.
Comment: Unusual spending = Cost anomaly hence B
Comment: https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/
Comment: AWS Glue with Athena (Option B): AWS Glue is a fully managed extract, transform, and load (ETL) service, and Athena is a serverless query service that allows you to analyze data directly in Amazon S3 using SQL queries. By configuring an AWS Glue crawler to crawl the data, you can create a schema for the data, and then use Athena to query the data directly without the need to load it into a separate database. This minimizes operational overhead.
Comment: You`ve come a loooong way...keep going... Kinesis Data Analytics applications continuously read and process streaming data in real time. Data is already at rest in S3. So Athena. https://docs.aws.amazon.com/kinesisanalytics/latest/dev/how-it-works.html
Comment: It says to quickly analyze the data, Athena can't do it so it's D
Comment: Option B - leverages serverless services that minimise management tasks and allows the company to focus on querying and analysing the data with the LEAST operational overhead.
Comment: Neither Glue nor EMR nor Kinesis are used "to query the data"
Comment: A: DataSync is not used for this C: FSx File Gateway requires NFS on both sides so won't work with S3 D: Doesn't say how to transfer data to S3 B: S3 File Gateway will connect SMB to S3. Lifecycle policy will move objects to S3 Glacier Deep Archive which support 12 hours retrieval https://aws.amazon.com/blogs/aws/new-amazon-s3-storage-class-glacier-deep-archive/
Comment: It feels like C is there just to mess with everyone
Comment: Not C because FSx File Gateway saves files in FSx for Windows file server, not S3. Not D because users should acess the files via SMB
Comment: "FSx File Gateway saves files in FSx for Windows File Server, not S3" -- me spreading misinformation on the Internet >:)
Comment: While it is optimized for compatibility with Windows environments, the files stored in Amazon S3 through the FSx File Gateway are not limited to Windows-only access.
Comment: Answer is B, Amazon S3 File Gateway supports SMB and NFS, Amazon FSx File Gateway SMB for windows workloads.
Comment: S3 file gateway supports SMB and S3 Glacier Deep Archive can retrieve data within 12 hours. https://aws.amazon.com/storagegateway/file/s3/ https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html
Comment: I prefer to choose Amazon S3 File Gateway. https://docs.aws.amazon.com/filegateway/latest/files3/file-gateway-concepts.html
Comment: Amazon FSx File Gateway with S3 Lifecycle policy (Option C): Amazon FSx is a fully managed file storage service, and with a File Gateway, it allows seamless integration between on-premises file servers and AWS storage. By creating an Amazon FSx File Gateway and implementing an S3 Lifecycle policy to transition data to S3 after 7 days, you can achieve the desired storage and retrieval characteristics.
Comment: Wrong. An "FSx File Gateway" stores the files on AWS side in FSx for Windows file server, NOT in S3. Thus you can't apply the "S3 Lifecycle Policy".
Comment: A: RDS DB instance Autoscaling is not a thing C: You cannot read from standby even if this was done. E: Does not solve any problem Correct answer B: Read replicas distribute load and help improving performance D: Caching of any kind will help with performance Remember: " The database experiences a heavy read load during periods of high traffic."
Comment: RDS auto scaling helps capacity issue, not heavy read workload issue.
Comment: By creating a read replica, you offload read traffic from the primary DB instance to the replica, distributing the load and improving overall performance during periods of heavy read traffic. Amazon ElastiCache can be used to cache frequently accessed data, reducing the load on the database. This is particularly effective for read-heavy workloads, as it allows the application to retrieve data from the cache rather than making repeated database queries.
Comment: i think we need Multi az DB, wtih ElastiCache
Comment: Not A - There is no such thing as "auto scaling for a DB instance". There is automatic storage scaling, but storage is not the issue here. B - Yes, read replica will help with "heavy read load" Not C - "send read traffic to the standby DB instance" does not work D - "Configure the application ..." might be a bit simplified, but Elasticache helps with read load Not E - That might have impact on latency, but not on database load; and all instances in same AZ would be against WAF
Comment: Amazon RDS does support Storage Auto Scaling :) https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/
Comment: Storage auto scaling is not same as instance autoscaling. Storage is not a problem here.
Comment: A and B should be most correct ans
Comment: A is autoscaling for DB, it won't fix read problem.
Comment: Should be A and B
Comment: B. Create a read replica for the DB instance. Configure the application to send read traffic to the read replica. By creating a read replica, you offload read traffic from the primary DB instance to the replica, distributing the load and improving overall performance during periods of heavy read traffic. D. Create an Amazon ElastiCache cluster. Configure the application to cache query results in the ElastiCache cluster. Amazon ElastiCache can be used to cache frequently accessed data, reducing the load on the database. This is particularly effective for read-heavy workloads, as it allows the application to retrieve data from the cache rather than making repeated database queries.
Comment: ElastiCache requires application changes, "the solutions architect" cannot simply "configure the application to cache query results".
Comment: On second thought, this might still be correct. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/creating-elasticache-cluster-with-RDS-settings.html
Comment: Locking EBS Snapshots (Option D): The "lock" feature in AWS allows you to prevent accidental deletion of resources, including EBS snapshots. This can be set at the snapshot level, providing a straightforward and effective way to meet the requirements without changing the administrative rights of the storage administrator user.
Comment: correct option D
Comment: I will go for D
Comment: D: Exactly what a locked EBS snapshot is used for https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-snapshot-lock.html
Comment: Typical use case for object lock aka D
Comment: CloudTrail is for logging administrative actions, we need CloudWatch. We want the data in another AWS service (OpenSearch), not Kinesis, thus we need Firehose, not Streams.
Comment: base on the research, it should be Answer A, because question is asking for a "near real time" which Kinesis Data Stream is offering the data with less than 1 second latency. But Kinese Data Firehost is offering the data with more than 1 second. https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html#integrations-kinesis https://stackoverflow.com/questions/44608274/is-there-any-difference-in-processing-times-between-aws-kinesis-firehose-and-str https://docs.aws.amazon.com/streams/latest/dev/using-other-services-cw-logs.html
Comment: base on the research, it should be Answer A, because question is asking for a "near real time" which Kinesis Data Stream is offering the data with less than 1 second latency. But Kinese Data Firehost is offering the data with more than 1 second. https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html#integrations-kinesis https://stackoverflow.com/questions/44608274/is-there-any-difference-in-processing-times-between-aws-kinesis-firehose-and-str
Comment: log analysis place= aws cloudwatch log data capturing on the entire vpc=aws flow log near real time data analysis and send to OpenSearch service= kinesis data fire hose
Comment: OpenSearch patterns for CloudWatch Logs: 1) "Near Real Time": CloudWatch logs --> Subscription Filter --> Kinesis Data Firehose --> Amazon OpenSearch (option *B*) 2) "Real Time": CloudWatch logs --> Subscription Filter --> Lambda --> Amazon OpenSearch
Comment: Amazon CloudWatch Logs and VPC Flow Logs (Option B): VPC Flow Logs capture information about the IP traffic going to and from network interfaces in a VPC. By configuring VPC Flow Logs to send the log data to a log group in Amazon CloudWatch Logs, you can then use Amazon Kinesis Data Firehose to stream the logs from the log group to Amazon OpenSearch Service for analysis. This approach provides near real-time streaming of logs to the analytics service.
Comment: I think the question is easy to misunderstand, whether you should create the whole setup or just the development cluster. But from the wording ("The [production] EKS cluster has (!) managed node groups ... The company needs a dedicated EKS cluster for development work"), I conclude that we should only create the development cluster. As this will be used "infrequently" for testing purposes only, and it must be "most cost-effective", I'd go with A - new cluster with "one managed node group that contains only Spot instances".
Comment: I hate this question.... I think I will go with B just because wording also. A company is developing an application that "WILL" run on a production Amazon Elastic Kubernetes Service
Comment: The wording of question and options is so confusing. The last line is a throw off also "The EKS cluster must manage all the nodes" Which EKS cluster? A new one or the existing one. Both A and B are correct depending on how you decipher the question. I really hope the exam question uses better language!
Comment: If we look closer to the last requirement "The EKS cluster must manage all the nodes." Option B is the only feasable and cost-effective one.
Comment: Based on the document [1], we can know that only self-managed node group can deploy the container on EC2 dedicated hosts . Which mean that customer need to manually create launch template, auto scaling group, and register it to the EKS cluster. The creation process should be same as general EC2 auto scaling creation. For now, EKS managed node group only supported on-demand and spot. MOST cost-effectively: *Spot Instances* https://repost.aws/questions/QUugoX4f1gRHW0MGHRTHFFFA/how-to-create-eks-cluster-with-dedicated-host-node-group
Comment: This question is convoluted and missing some details. We need: - control plane running on on-demand EC2s - worker nodes running on spot instances Read this to understand correct solution: https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-provisioning-and-managing-ec2-spot-instances-in-managed-node-groups/
Comment: "The company will use the development cluster infrequently to test the resiliency of the application" = Spot instances = cost effective
Comment: The keywords are infrequent and resiliency.. This solution allows you to have a mix of On-Demand Instances and Spot Instances within the same EKS cluster. You can use the On-Demand Instances for the development work where you need dedicated resources and then leverage Spot Instances for testing the resiliency of the application. Spot Instances are generally more cost-effective but can be terminated with short notice, so using a combination of On-Demand and Spot Instances provides a balance between cost savings and stability. Option A (Create a managed node group that contains only Spot Instances) might be cost-effective, but it could introduce potential challenges for tasks that require dedicated resources and might not be the best fit for all scenarios.
Comment: The GBT vote A, I know the spot instance is the cheapest, but the question says "dedicated EKS cluster for development", so I vote B
Comment: Option A leverages the cost savings of Spot Instances, which is ideal for a development environment where the application is tested infrequently, and there is flexibility in when the nodes can be interrupted. This aligns with the goal of cost-efficiency and takes advantage of EKS's ability to manage the nodes directly.
Comment: B is the best ans.
Comment: Why do you think so?
Comment: Option B
Comment: Why do you think so?
Comment: SSE-KMS with Customer Managed Key (Option B): This option allows you to create a customer managed key using AWS KMS. With a customer managed key, you have full control over key lifecycle management, including the ability to create, rotate, and disable keys with minimal effort. SSE-KMS also integrates with AWS Identity and Access Management (IAM) for fine-grained access control.
Comment: Having both awsgeek75 and pentium75 in the comment section makes me more confident about my own answers.
Comment: Customer needs to control the 'user's ability' and not the management of the keys. Option C will prevent users to have this ability.
Comment: Has to be customer manages to AC are not useful D is just wrong way of doing this B give full control to customer while using S3 server side encryption.
Comment: A and C do not allow the company "to fully control the ability of users to create, rotate, and disable encryption keys". D is anything but "minimal effort".
Comment: Option B should be correct
Comment: This is a good example for a completely non-sense AWS exam question. In order to delete the object like requested in the question you need (E). This is required in either versioned or non-versioned buckets. Basically the task is done here. But let's assume we want to make it extra secure and retain the files for 30 days. Then we need object lock (A). You cannot have object lock without versioning (B). You also need to set a retention period then (C). So you either have A,B,C,E or you have E. Choosing exactly 3 options is completely nonsense here. But what do i know.
Comment: "Object Lock works only in buckets that have S3 Versioning enabled" However, we can't have 2 options (A and B) telling to create the bucket. So, A is only possible if versioning is already enabled. We need retention period (C), since this is not a case for legal holds: "Object Lock provides two ways to manage object retention: retention periods and legal holds." E - obvious reasons. Ref. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Comment: this is shit
Comment:
1- The S3 backups must be retained for 30 days -->
For that you must enable S3 Object Lock (versioning must be enabled) in Compliance Mode and set Retention Period to 30 days. Thus, to achieve this you need 3 options
Comment: B: No versioning is required D: Lifecycle is for transitioning or expiring. There is no protection lifecycle policy F: No such tag Enable object lock, retain for 30 days (https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops-retention-date.html) and expire after 30 days.
Comment: "Object Lock works only in buckets that have S3 Versioning enabled" However, I still agree with ACE, since the bucket has already been created, so we can't have 2 answers telling to create the bucket. And yes, for this case, we need retention period: "Object Lock provides two ways to manage object retention: retention periods and legal holds." Ref. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Comment: I meant ACE! not ADE!
Comment: In theory, E alone would be enough because the objects are "retained for 30 days" without any configuration as long as no one deletes them. But let's assume that they want us to prevent deletion. A: Yes, required to prevent deletion. Object Lock requires Versioning, so if we 'create an S3 bucket that has S3 Object Lock enabled' that this also has object versioning enabled, otherwise we would not be able to create it. B: No. We need versioning, but we cannot "create" the bucket twice. If we create it "with object lock enabled" then versioning is enabled too, but NOT the other way round (creating it with versioning enabled will not automatically enable object lock).
Comment: C: Yes, "default retention period" specifies how long object lock will be applied to new objects by default, we need this to protect objects from deletion. D: No, S3 Lifecycle Policy can "transition" or "expire" but not "protect". E: Yes, this will delete the objects after 30 days (C just removes the object lock after 30 days but does not delete the objects). F: No, 'tag with a retention period' is not common AWS wording, "tags" are something different in AWS context
Comment: ABE -> https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html A. Create an S3 bucket that has S3 Object Lock enabled. -> You set a Retention period of 30 days with this feature. B. Create an S3 bucket that has object versioning enabled -> Object Lock works only in buckets that have S3 Versioning enabled E. Configure an S3 Lifecycle policy to expire the objects after 30 days. -> It is valid using the lifecicle policy.
Comment: After analyzing the question deeply and reading: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html, I keep A and B, change E per C. A. Create an S3 bucket that has S3 Object Lock enabled. B. Create an S3 bucket that has object versioning enabled. Change E must be automatically deleted after 30 days(objects will be marked as expired not deleted). per C. Configure a default retention period of 30 days for the objects. It feature delete the object.
Comment: Selected Answer: ACE A. Create an S3 bucket that has S3 Object Lock enabled. Enable the S3 Object Lock feature on S3. C. Configure a default retention period of 30 days for the objects. To lock the objects for 30 days. E. Configure an S3 Lifecycle policy to expire the objects after 30 days. -> to delete the objects after 30 days.
Comment: ACE is the correct ans.
Comment: ADE should be correct
Comment: Why? S3 Lifecycle Policy can "transition" or "expire" but not "protect" https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html
Comment: Correct Answer is A C E
Comment: A. Create an S3 bucket that has S3 Object Lock enabled. S3 Object Lock provides the ability to enforce retention periods on objects, preventing deletion or modification for a specified duration. D. Configure an S3 Lifecycle policy to protect the objects for 30 days. By configuring a lifecycle policy, you can define a transition action to move objects to the S3 Glacier storage class (or any other storage class) after 30 days. E. Configure an S3 Lifecycle policy to expire the objects after 30 days.
Comment: S3 Lifecycle Policy can "transition" or "expire" but not "protect" https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html
Comment: DataSync will do an Initial Scan of both S3 buckets. Identifying Differences. Then, Transferring Changes, so technically DataSync will transfer All the data at first run then it will only transfer newly added/modified objects subsequently.
Comment: Have always did this using B, guess now that I know A is less operational
Comment: BD are more operation overhead although B can work in principle AC uses managed service to transfer data. A fulfils the requirement of "copied files should be overwritten only if the source file changes" so A is correct. B will just copy regardless of the change
Comment: Meant C will transfer everything and copy data without comparing for change
Comment: Transfer only data that has changed – DataSync copies only the data and metadata that differs between the source and destination location. Transfer all data – DataSync copies everything in the source to the destination without comparing differences between the locations. https://docs.aws.amazon.com/datasync/latest/userguide/configure-metadata.html (B would work too but is more "operational overhead.")
Comment: ans: A
Comment: AWS DataSync (Option A): AWS DataSync is designed for efficient and reliable copying of data between different storage solutions. By setting up an AWS DataSync task with the transfer mode set to transfer only data that has changed, you ensure that only the new or modified files are copied. This minimizes data transfer and operational overhead.
Comment: Actually this is not fully correct: "By setting up an AWS DataSync task with the transfer mode set to transfer only data that has changed, you ensure that only the new or modified files are copied. " "Transfer only data that has changed ... copies only the data and metadata that differs between the source and destination location." So, if we have a source with existing items and an empty destination (like in this example), "transfer only data that has changed" will transfer all the existing items though in the true sense of the word they have not "changed".
Comment: The company must be able to control rotation of the encryption keys = customer managed key
Comment: "The company must be able to control rotation of the encryption keys." BD does not allow company owned keys C is too much operational overhead
Comment: The solution that meets the requirements with the LEAST operational overhead is: B. Use an AWS managed key to encrypt the EBS volumes. Use the key to configure automatic key rotation. With AWS managed keys (AWS managed CMKs), AWS takes care of key management tasks, including key rotation. This reduces operational overhead as AWS automatically handles key rotation without requiring manual intervention. It is a convenient option for users who want to ensure encryption at rest with minimal effort in managing encryption keys.
Comment: AWS Manged keys don't meet the requirements "The company must be able to control rotation of the encryption keys."
Comment: A is correct option
Comment: "Able to control rotation of the encryption keys" = customer managed key (created by AWS but managed by the customer in KMS)
Comment: Answer is C Details are on this link below: https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html Amazon S3 buckets have bucket encryption enabled by default, and new objects are automatically encrypted by using server-side encryption with Amazon S3 managed keys (SSE-S3). This encryption applies to all new objects in your Amazon S3 buckets, and comes at no cost to you. If you need more control over your encryption keys, such as managing key rotation and access policy grants, you can elect to use server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS), or dual-layer server-side encryption with AWS KMS keys (DSSE-KMS). For more information about SSE-KMS, see Specifying server-side encryption with AWS KMS (SSE-KMS). For more information about DSSE-KMS, see Using dual-layer server-side encryption with AWS KMS keys (DSSE-KMS).
Comment: How does this relate to answer C? With "imported key material" you cannot "control rotation of the encryption keys" (except by importing new keys). SSE-KMS (as mentioned in your explanation = customer managed key = A
Comment: Should be option A
Comment: option B is the correct answer with least operational overhead on admins
Comment: @meenkaza was right the answer is A
Comment: AWS managed keys do allow for automatic rotation, but the company does NOT have control over the rotation - AWS manages this automatically without company intervention.
Comment: option A (Create a customer managed key. Use the key to encrypt the EBS volumes) is the most suitable option with the least operational overhead for the given requirements.
Comment: IAM Policy and AWS Config (Option A): By creating an IAM policy that allows users to create only encrypted EBS volumes, you proactively prevent the creation of unencrypted volumes. Using AWS Config, you can set up rules to detect noncompliant resources, and AWS Systems Manager Automation can be used for automated remediation. This approach provides a proactive and automated solution.
Comment: Isn't B simpler?
Comment: B: Too much work C: Macie is for PII and sensitive data not for encrypted volumes D: Inspector for OS patching and vulnerability detections
Comment: why not B?
Comment: Option A - enforces the creation of encrypted volumes via IAM policies and uses AWS Config for detection and AWS Systems Manager for remediation with the LEAST administrative overhead.
Comment: A as exactly described here: https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automatically-encrypt-existing-and-new-amazon-ebs-volumes.html Not B, that could in theory work but would be massive operational overhead Not C, Macie detects PII data, not unencrypted volumes Not D, Inspector detects vulnerabilities, not unencrypted volumes
Comment: Web Tier Migration (Option A): Migrating the web tier to Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) provides horizontal scalability, automatic scaling, and improved resiliency. Auto Scaling helps in managing and maintaining the desired number of EC2 instances based on demand, and the ALB distributes incoming traffic across multiple instances. Database Migration to Amazon RDS Multi-AZ (Option C): Migrating the database to Amazon RDS in a Multi-AZ deployment provides high availability and automatic failover. In a Multi-AZ deployment, Amazon RDS maintains a standby replica in a different Availability Zone, and in the event of a failure, it automatically promotes the replica to the primary instance. This enhances the resiliency of the database.
Comment: A - ALB is ideal for web application B - NLB would work too but ALB is better C - same functionality as on-premises just with 'improved resiliency' D - would require significant "changes to the application" E - would require significant "changes to the application"
Comment: Also Dynamo DB is noSQL, that can not be an option here
Comment: option A C
Comment: "AWS Local Zones are a type of AWS infrastructure deployment that place compute, storage, database, and other select services closer to large population, industry, and IT centers, enabling you to deliver applications that require single-digit millisecond latency to end-users." A and C tell us to "deploy the applications in eu-central-1" which is exactly what we're not supposed to do. AWS Wavelength zones are AWS deployments in CSP's networks, has nothing to do with this question. https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/?nc1=h_ls
Comment: AC is not right "Because of regulations, the company cannot launch some of its applications in eu-central-1" D: AWS Wavelength is for mobile network B: Local Zones can be used to launch apps close to a region but not in a region like EUC1 so this works
Comment: Correct B: AWS Local Zones are an extension of AWS infrastructure and bring AWS services closer to end-users, providing ultra-low latency for applications that require single-digit millisecond latencies. By deploying the applications in AWS Local Zones, the company can meet the latency requirements while also complying with regulations that prevent certain applications from being hosted in the eu-central-1 Region.
Comment: Option B - AWS Local Zones place AWS compute, storage, database, and other select services closer to end-users. This would allow the company to deploy applications within geographic proximity to eu-central-1 without being directly in the region, potentially meeting regulatory requirements and achieving low latency. Whereas Option D - AWS Wavelength Zones are designed to provide developers the ability to build applications that deliver single-digit millisecond latencies to MOBILE and connected devices. And it's more focused on 5G Apps and may not be directly relevant to Web Apps hosting.
Comment: I would go also for B, was in doubt from B or D but I aggree with pentium75 the wavelenght zones are not designed for this use case however AWS local zones can provide single-digit milisecond latency as described in the link https://aws.amazon.com/about-aws/global-infrastructure/localzones/
Comment: option B
Comment: AWS Wavelength (Option D): AWS Wavelength Zones bring AWS services to the edge of the 5G network, providing ultra-low latency for applications that require single-digit millisecond latencies. Deploying applications in Wavelength Zones allows the company to extend its VPC from the eu-central-1 Region to the chosen Wavelength Zone, providing the required low-latency access.
Comment: "Wavelength Zones are AWS infrastructure deployments that embed AWS compute and storage services within communications service providers' (CSP) 5G networks". They reduce latency for mobile users in the CSP's network, but this is not asked here. Local Zones provide "single-digit millisecond latency".
Comment: It looks like D is correct from diagram in the following url. https://docs.aws.amazon.com/wavelength/latest/developerguide/how-wavelengths-work.html
Comment: Option B. Reduce number of connection to RDS -> RDS Proxy. "A Lambda function that's outside of a VPC can't access an RDS instance that's inside a VPC." https://repost.aws/knowledge-center/connect-lambda-to-an-rds-instance
Comment: Have to be inside VPC in order to access the RDS instance for Lambda
Comment: Option B. Reduce number of connection to RDS -> RDS Proxy. "A Lambda function that's outside of a VPC can't access an RDS instance that's inside a VPC." https://repost.aws/knowledge-center/connect-lambda-to-an-rds-instance
Comment: Same as question 802 in SAA-C02
Comment: Anytime I see "the number of VPCs will increase", I immediately look for "transit gateway" as the least administrative overhead.
Comment: "AWS Transit Gateway provides a hub and spoke design for connecting VPCs and on-premises networks as a fully managed service without requiring you to provision third-party virtual appliances. No VPN overlay is required, and AWS manages high availability and scalability." https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html#:~:text=AWS%20Transit%20Gateway%20provides%20a,manages%20high%20availability%20and%20scalability.
Comment: Transit Gateway enables customers to connect thousands of VPCs. You can attach all your hybrid connectivity (VPN and Direct Connect connections) to a single gateway, consolidating and controlling your organization's entire AWS routing configuration in one place (refer to the following figure)
Comment: high number of accounts and VPC to conect to on prem _> exactly the transit gateway use case
Comment: multiple on-premises locations + increasing number of accounts and VPCs --> connections using *transit gateway*
Comment: Hi, Seems like after question 684, the discussion are quite less and seems recent comments. Are these new sets of questions updated? Anyone having any idea around this?
Comment: Anytime I see "the number of VPCs will increase", I immediately look for "transit gateway" as the least administrative overhead.
Comment: vote for C
Comment: I think its C. LEAST administrative overhead. D can work but AWS direct connection and VPC peering configure require too much administrative overhead
Comment: Think C would be the correct answer here.
Comment: so what about AB since the Forcase is no logner available to new customers?
Comment: Amazon Forecast is no longer available to new customers. https://aws.amazon.com/blogs/machine-learning/transition-your-amazon-forecast-usage-to-amazon-sagemaker-canvas/
Comment: "Amazon Forecast is no longer available to new customers. Existing customers of Amazon Forecast can continue to use the service as normal" "After careful consideration, we have made the decision to close new customer access to Amazon Forecast, effective July 29, 2024." This question will either be removed or reformulated to exclude Forecast as the service is no longer available to new customers.
Comment: Amazon forecast can be trained by using data from S3: https://docs.aws.amazon.com/forecast/latest/dg/getting-started.html
Comment: Because of these assertions - The company has no machine learning (ML) experience - The comapny wants to use a managed service We could tempted to go for SageMaker that is the core AWS managed service for ML purposes . But, but, if we consider this valuable information: - A company that uses AWS needs a solution to predict the resources needed for manufacturing processes. With a bit research, we will find out that AWS also hold time-series forecasting service based on machine learning (ML). https://aws.amazon.com/forecast/?nc1=h_ls So i understand options DE are the best answers enven thought this service is not mentionned anywhere in current SAA-C03 course version
Comment: BE from CHATGPT
Comment: SageMaker and Forecast can directly utilize data within an S3 B) E) https://aws.amazon.com/blogs/compute/build-workflows-for-amazon-forecast-with-aws-step-functions/ https://docs.aws.amazon.com/sagemaker/latest/dg/train-model.html
Comment: A + B dude
Comment: Yes, exactly. Steps B and A together constitute a comprehensive solution: - Step B involves using Amazon SageMaker to train a machine learning model using historical data stored in the S3 bucket. - Step A involves deploying the trained model as a SageMaker endpoint, allowing for real-time inference on new data. This combination leverages Amazon SageMaker's managed services for both training and inference, meeting the company's requirements efficiently.
Comment: A & B: B. Amazon SageMaker is a managed service that provides built-in algorithms and tools for training machine learning models. You can use SageMaker to train a model using historical data stored in an S3 bucket. This meets the requirement of utilizing a managed service for training the model without requiring machine learning experience. A. Once the model is trained using SageMaker, you can deploy it by creating a SageMaker endpoint for inference. This endpoint allows you to make predictions based on new data, fulfilling the requirement of predicting resources needed for manufacturing processes each month.
Comment: *E*: Amazon Forecast is a fully managed service that uses machine learning (ML) to generate highly accurate forecasts without requiring any prior ML experience. Forecast is applicable in a wide variety of use cases, including estimating product demand, energy demand, workforce planning, computing cloud infrastructure usage, traffic demand, supply chain optimization, and financial planning. *D*: Publish demand using AWS Lambda, AWS Step Functions, and Amazon CloudWatch Events rule to periodically (hourly) query the database and write the past X-months (count from the current timestamp) demand data into the source Amazon S3. https://aws.amazon.com/blogs/machine-learning/automating-your-amazon-forecast-workflow-with-lambda-step-functions-and-cloudwatch-events-rule/
Comment: B & D is the right choice
Comment: My votes are for DE based on statement from AWS site: "Alternatively, if you are looking for a fully managed service to deliver highly accurate forecasts, without writing code, we recommend checking out Amazon Forecast. Amazon Forecast is a time-series forecasting service based on machine learning (ML) and built for business metrics analysis." https://aws.amazon.com/blogs/machine-learning/deep-demand-forecasting-with-amazon-sagemaker/
Comment: Why E?
Comment: Explanation: Training the Model with SageMaker (Option B): Use Amazon SageMaker to train a machine learning model based on historical data. SageMaker simplifies the process of training, deploying, and managing machine learning models. Creating Predictions with Amazon Forecast (Option D): Use Amazon Forecast to create a predictor based on historical data. Forecast is designed for time-series forecasting, making it suitable for predicting resources needed for manufacturing processes each month. Combining SageMaker for training and Amazon Forecast for predictions provides a comprehensive solution, and AWS Lambda can be used to integrate these services into your workflow.
Comment: combination of steps so it cannot be B,D. B D is two different solution
Comment: BE looks correct
Comment: C is least overhead
Comment: Check out this one. https://www.youtube.com/watch?v=y_n9xN5mg1g
Comment: https://docs.aws.amazon.com/controltower/latest/userguide/sso.html
Comment: Correct is C
Comment: The correct answer should be C
Comment: D: no-brainer.
Comment: D looks right
Comment: AWS Config allows you to define rules to automatically check the configuration of AWS resources against desired configurations. By creating a custom AWS Config rule specifically for Amazon EBS volumes to evaluate if they are encrypted, you can ensure consistent encryption across all volumes. If a volume is found to be unencrypted, it can be flagged for further action. This solution automates the process of encryption checking, minimizing manual effort and ensuring standardization across the environment. Additionally, AWS Config provides a cost-effective solution compared to continuously running scripts or tasks.
Comment: AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. It can check whether your resources comply with certain conditions (such as being encrypted), and it can flag or take action on resources that do not comply.
Comment: D : you could use a managed rule to quickly start assessing whether your Amazon Elastic Block Store (Amazon EBS) volumes are encrypted or whether specific tags are applied to your resources. https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html
Comment: Correct answer is D
Comment: CD C: Increase the file upload throughput D: increase the file download throughput
Comment: C: Upload: Multipart clear, D: Download: You can fetch a byte-range from an object, transferring only the specified portion. You can use concurrent connections to Amazon S3 to fetch different byte ranges from within the same object. This helps you achieve higher aggregate throughput versus a single whole-object request. A: S3 Access Points can be easily scaled, but are typically used to simplify data access for any AWS service or customer application that stores data in S3. E: Prefixes: You can increase your read or write performance by using parallelization. For example, if you create 10 prefixes in an Amazon S3 bucket to parallelize reads, you could scale your read performance to 55,000 read requests per second. But wording in this answer is strange...
Comment: C&D are correct
Comment: Cd are correct
Comment: C &D Correct
Comment: CD are the correct options
Comment: CD is the correct for me
Comment: Correct answer is CD
Comment: Correct answer BE
Comment: Regarding storage, I'd go for EFS, although it never mentions the requirement for file storage. Datasync can copy data between several storage types, including EFS, agents can be installed on EC2, but you cannot perform continuous synchronization of EC2 instances. Only storage. Cloudfront can publish both passive (s3) and active content (EC2+EFS) but wording doesn't tell a thing about such a share. And if it's a passive site why do we even have 2 storage types... I'd say, for me, the least bad solution seems to be B + E.
Comment: I choose BE
Comment: BD looks most logical to me - continuous changes required an update via DataSync
Comment: B & E seems to be the most logic
Comment: 1. Given the chance >always use Alias over a Cname< 2. Latency-based routing is for user experience. (low latency) Failover is for DR, Geolocation for local restrictions/rights/language/currency, and geo-proximity is a more complex, biased location-based routing, not part of the SA Associate exam.
Comment: Alias?! "A record" is NOT an Alias record; it's an ADDRESS RECORD. There's a difference in between an address record (A record) & an Alias. An Address record will map to 1 or more IP addresses. An Alias record will map to another name like a CNAME does. We eliminate C&D bc we need an IP address that will give us the best performance; we distribute traffic to a certain IP address based on policy. geolocation policy is defined by where the request comes from. latency policy is defined by how fast (performance) we can reply.
Comment: Geoproximity Policy routing users to resources based on their geographic location, routing based on geographic location may not always be the absolute lowest latency. latency-based routing prioritizes user experience.
Comment: A is true
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
Comment: The correct is D, the question says "using an Application Load Balancer" the ALB has a DNS name assigned not an IP. A type A record will only allow you to point to an IPv4. If I'm wrong, happy to be corrected.
Comment: Answer A is correct. Route53 uses an internal record type called ALIAS, but from a DNS point of view it's still an A record. Just try it yourself, create an ALB and create a DNS record in Route53. While you can technically use a CNAME (for subdomains, see below), the wizard will guide you to use an A ALIAS record, which also makes the most sense. The problem with CNAME records is that it's not possible to create them at the root level of the domain. Let's say your domain is somedomain.com - you can't create a CNAME for the apex of the domain (mydomain.com), only for subdomains (subdomain.mydomain.com). https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
Comment: ChatGPT: The most high-performing experience in this scenario would be achieved by using: D. Create a CNAME record with a geoproximity policy. Geoproximity routing allows you to route traffic based on the geographic location of your users and your resources. This would distribute traffic to the AWS Region that is closest to the user, optimizing performance by reducing latency. It's particularly useful when deploying applications across multiple regions to ensure users are directed to the closest region, minimizing network latency and providing the best user experience.
Comment: And, exactly, this is the reason why you should not rely on a LANGUAGE MODEL when you need a solution architect's advice .
Comment: A https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html
Comment: Based on previous questions, I believe A is correct. Because; the closest geolocated server doesn't necessarily provide the best performance. Geolocated load balancing is mostly used for serving location-specific content.
Comment: Q. What is Amazon Route 53's Latency Based Routing (LBR) feature? LBR (Latency Based Routing) is a new feature for Amazon Route 53 that helps you improve your application's performance for a global audience. You can run applications in multiple AWS regions and Amazon Route 53, using dozens of edge locations worldwide, will route end users to the AWS region that provides the lowest latency. https://aws.amazon.com/route53/faqs/
Comment: Why would you use a CNAME record?? Most suitable seems to be option B
Comment: Not really sure but ALBs do not have a static ip address they have domains assigned to them and also an Elastic ip can't be attached to an ALB. So mainly a cname would be preferred here.
Comment: But generally speaking it's not a bad idea. But yes A record alias name can point to it. and i don't think it's B cause even if it's geolocation it may not always result in a high-performing exp.
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html
Comment: Sorry changing to B.
Comment: D looks correct.
Comment: I honestly don't think you can use db Migration service to migrate an embedding db.
Comment: DDDDDDDDDDDDDDDDDD
Comment: Option D: let focus on HA + Scaling
Comment: ASG for application HA + DynamoDB Scale for HA
Comment: B as it's highly available and has less operational overhead than D.
Comment: ALB -> NLB makes no sense and solution lacks HA for the app layer.
Comment: But wouldn't migrating an embedded database to a new one introduce operational overhead now and in the future?
Comment: No, the very opposite: "Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database that runs high-performance applications at any scale."
Comment: DynamoDB + Modifying the Auto Scaling group
Comment: Dynamo DB presents more advantages, because it would need less administrative effort
Comment: The correct option should be D
Comment: B looks correct
Comment: • ElastiCache is a managed in-memory data store service that is well-suited for managing session data in a distributed architecture.
Comment: why not A?
Comment: because data to store(cache) will be bigger in size
Comment: session data must be available even if the user is disconnected and reconnects -> ElastiCache for Redis
Comment: *B*: ELB <--> ASG <--> ElastiCache <--> DynamoDB
Comment: B looks correct
Comment: Option B Amazon CloudWatch Container Insights: This service provides monitoring and troubleshooting capabilities for containerized applications. It collects and aggregates metrics, logs, and events from Amazon EKS clusters and containers. This helps in monitoring the performance and health of microservices.
Comment: Correct answer is B
Comment: B is the correct answer. Use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. https://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/ContainerInsights.html AWS X-Ray collects data about requests that your application serves, and it helps you view, filter, and gain insights into that data to identify issues and opportunities for optimization. https://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/logging-monitoring-for-application-owners/x-ray.html
Comment: C looks correct
Comment: Actually I think neither B or C is correctly worded. If talking about key policy, should be "Modify the key's policy to grant the IAM user permissions for the kms:GenerateDataKey and kms:Decrypt actions at minimum." If talking about bucket policy, should be "Deny GetObjects of particular customer without condition kms key equals 1234abcd...."
Comment: Encryption at rest --> KMS Each customer must be able to access only their data --> KMS Key Policies
Comment: B. Here's why this option is the best fit: Server-Side Encryption: Encrypting data server-side with KMS ensures encryption happens transparently within AWS, eliminating the need for complex client-side management and potential security risks associated with user-managed keys. Customer-Specific Keys: Utilizing separate KMS keys for each customer provides granular access control and encryption isolation. Each customer can only decrypt their data using their specific KMS key. S3 Bucket Policy: By denying decryption permissions for all principals except the dedicated customer IAM role in the S3 bucket policy, unauthorized access, even from company employees, is prevented. This aligns with the requirement of customer-specific data access.
Comment: Option C From Chapt Option A is incorrect because using ACM certificates is typically for establishing secure communication over HTTPS and doesn't directly relate to encrypting data at rest in S3. Option B is incorrect because while it suggests using AWS KMS keys for encryption, it mentions using S3 bucket policies for access control, which would not be appropriate for controlling decryption permissions. Option D is incorrect because it suggests using ACM certificates for client-side encryption, which is not typically used for encrypting data at rest in S3, and the approach described would not effectively control access to the encrypted data.
Comment: Correct answer should be C
Comment: Not A - Autoscaling Irrelevant B - ALB, route tales for the public subnet with a route to Priv subnet C - "NAT gateway" is "to allow [outbound] internet traffic", but this is about inbound traffic D - Instances are in the private subnet, therefore it wont work from the public.
Comment: Why not "D"?
Comment: nsure that the security group attached to the EC2 instance allows inbound traffic on ports 80 and 443 from the desired sources (e.g., any IP or specific IP ranges). This allows external internet traffic to reach the web server running on the EC2 instance
Comment: B - because ALB do it better NAT
Comment: Option C from Chatgt
Comment: NAT Gateway outbound connections
Comment: NAT Gateway stays in public subnet, not in private subnet. So, C can't be.
Comment: B: Provision an internet-facing Application Load Balancer (ALB) in a public subnet makes more sense
Comment: B makes most sense
Comment: Changing to option D
Comment: C should be the correct answer
Comment: Overall, Amazon EFS provides a highly available, fault-tolerant, and shared storage solution with minimal operational overhead, making it the ideal choice for persisting data in an Amazon EKS Fargate cluster.
Comment: B bcs EBS only attack one EC2
Comment: B looks correct
Comment: B, The solution also must be shared between multiple application containers so attaching to each container is not a practical solution.
Comment: B is correct answer because it is high available - EBS isnt HA for that so A isn't dealing with request.
Comment: Option A... EBS with multi attach does not provide HA so option B is more appropriate.
Comment: It's just plain wrong. Not getting HA with EBS multi attach is really the least of your problems. Mounting a regular FS in read/write mode on more than one machine will cause data corruption. You'd need a clustered filesystem.
Comment: Correct answer is B
Comment: Mounting S3 in Fargate is not supported commonly. You'd have to make it manually. EFS is very well supported with Fargate. https://stackoverflow.com/questions/66391791/how-to-mount-s3-bucket-to-ecs-fargate-container https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/storage.html
Comment: B looks correct
Comment: EFS is listed like a best practice for this cases "ou can use Amazon ECS to run stateful containerized applications at scale by using AWS storage services, such as Amazon EFS, Amazon EBS, or FSx for Windows File Server, that provide data persistence to inherently ephemeral containers. The term data persistence means that the data itself outlasts the process that created it. "
Comment: B is correct
Comment: The company does not want to manage any servers or storage infrastructure. I would go with C
Comment: Both B and C work with AWS launch type. So you have to decide between EFS vs S3. How are you going to MOUNT s3 buckets in the containers?!
Comment: It's simply not good practice, unless you're confusing S3 with S3 storage gateway.
Comment: Correct answer should be AC
Comment: Agreed. When you add an internal Load Balancer or an Amazon EC2 instance endpoint in AWS Global Accelerator, you enable internet traffic to flow directly to and from the endpoint in Virtual Private Clouds (VPCs) by targeting it in a private subnet. The VPC that contains the load balancer or EC2 instance must have an internet gateway attached to it, to indicate that the VPC accepts internet traffic. However, you don't need public IP addresses on the load balancer or EC2 instance. You also don't need an associated internet gateway route for the subnet.
Comment: Gaming, TCP&UDP, HA, Low latency >> NLB + AWS Global Accelerator
Comment: Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP. NLB + GA for UDP, TCP
Comment: UDP -> NLB and Global Accelerator
Comment: Gaming + TCP / UDP => always think NLB and global accelerator
Comment: *AC* - the app is using TCP & UDP
Comment: For global user where TCP and UDP protocols are used and HA with minimum latency is needed.... Global Accelerator with NLB is the solution combination .
Comment: C is the correct answer
Comment: AnswerC
Comment: (A & D) are incorrect. AWS WAF Web ACL - contain WAF rules that define how to inspect web requests and what to do when a web request matches the inspection criteria. We don't have the inspection criteria necessary to use WAF Web ACL effectively bc DDoS attacks are originating from random IP addresses. The AWS DDoS Response Team can respond to the randomness. (B) is incorrect. Amazon Inspector - a service that analyzes your EC2 instances to identify potential security and configuration issues. Inspector is not good at dealing with an actual DDOS attack like AWS Shield Advanced.
Comment: DDoS = AWS Shield
Comment: C is the correct answer, AWS Shield Advanced.
Comment: C looks correct
Comment: C is the correct answer. Amazon Inspector is an automated vulnerability management service whereas AWS Shield Advanced is a managed service that helps you protect your application against external threats, like DDoS attacks, volumetric bots, and vulnerability exploitation attempts. For higher levels of protection against attacks.
Comment: C is the correct answer
Comment: Option D Option A, B, and C involve using Amazon S3 or Amazon EFS as an intermediary storage layer, which may introduce additional latency and overhead, not meeting the requirement of consistent sub-millisecond latency. Therefore, Option D is the most suitable solution for this scenario.
Comment: The format on the Snowball device would be s3 compatible only. The FSx for Lustre file system can be created and then linked to the S3 bucket. The Lustre file system can then be mounted on the HPC workloads that need sub-millisecond latency to storge data. Option B would be the correct option, assuming only S3 support on snowball.
Comment: No direct integration between Snowball and Fsx for Lustre. It must be via S3. Snowball Edge (Storage Optimized) --> S3 --integrate--> FSx for Lustre https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html https://aws.amazon.com/tw/blogs/aws/enhanced-amazon-s3-integration-for-amazon-fsx-for-lustre/
Comment: The correct answer is D for sure
Comment: You cannot import data from snowball in any other destination other than S3. So no, D is INCORRECT. Don't get tricked just because they mentioned HPC.
Comment: B for sure
Comment: Import data to AWS services: When AWS receives the device, the data is automatically imported into the designated AWS service or Amazon S3 bucket based on your configuration. For example, if you need to access the data from an HPC cluster running on AWS, you would import the data into an Amazon FSx for Lustre file system or Amazon S3, and then access it from your HPC cluster instances. No need S3 bucket
Comment: You cannot access the FSx for Lustre file system from the HPC cluster instances and this is only possible via S3
Comment: HPC = Lustre
Comment: Extension: HPC= Lustre, but Snowball = S3, therefore: B Sync from Snowball to S3 -> Link/integrate with Lustre Correct answer: C
Comment: Which is of course not C but B... :D Sorry... So correct answer: :D
Comment: B is right
Comment: Selected Answer: D is right answer because it mentions sub-millisecond latency and high-throughput access
Comment: B https://medium.com/@abylead/amazon-fsx-for-migration-and-certification-f3cb7b4dd843
Comment: B is correct
Comment: According to Copilot: Transferring data directly from AWS Snowball Edge to Amazon FSx for Lustre is not a standard process supported directly by AWS.
Comment: Option D, creating an Amazon FSx for Lustre file system and importing the data directly into it, is indeed the most suitable solution for this scenario. By bypassing an intermediary storage layer and directly importing the data into FSx for Lustre, the solution ensures optimal performance with consistent sub-millisecond latency and high throughput, meeting the requirements of the HPC cluster. Thank you for pointing out the clarity.
Comment: It should be B. No direct integration between Snowball and Fsx for Lustre
Comment: It must be via S3
Comment: Cali182 you cannot directly copy from Snowball Edge to FSx for luster
Comment: Its B. Snowball Edge (Storage Optimized) --> S3 --integrate--> FSx for Lustre
Comment: D is the correct answer
Comment: B is the correct option
Comment: A -> Used for ETL not copying B -> Works C -> Works, but overkill for the described scenario of periodic small backups, high cost D -> Works but it may not be necessary for transferring small amounts of data periodically. High setup cost
Comment: AnswerB Should be sufficient
Comment: B is the correct option
Comment: UDP needs NLB
Comment: UDP > NLB.
Comment: Ans : C OfCourse we can use both NLB and GLB balancers for UDP traffic but NLB is more cost effective than GLB that is why we choice C.
Comment: TCP/UDP = NLB
Comment: C ->https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
Comment: UDP -> NLB. ALB is for HTTP/HTTPS. Gateway Load Balancer is for 3rd party virtual appliances like Firewalls etc not the traffic distribution. https://aws.amazon.com/compare/the-difference-between-the-difference-between-application-network-and-gateway-load-balancing/#:~:text=An%20NLB%20operates%20on%20layer,level%20along%20with%20gateway%20functionality.
Comment: UDP, should use network load balancer
Comment: C, NLB
Comment: A: Correct. because need convert from MySQL to PostgreSQL B: Wrong. Schema Conversion does not create an Aurora read replica C: Wrong. Company wants to migrate to Aurora PostgreSQL, not Aurora MySQL D: Correct. CDC task helps to capture ongoing change from source data store E: Wrong. Although using Aurora Read Replica is an option for DB migration within the same Region, this question is asking for "combination of steps", which this option does not have another compatible option to pair with Therefore, answer is "AD"
Comment: AD makes sense to me, but I am not sure if that's the best answer.
Comment: Agreed. AD makes more sense !!
Comment: AnswerAD
Comment: Lag many never be zero, then it will ne er be promoted to primary
Comment: It's quite similar with Q.235, based on that discussion A-D makes more sense.
Comment: of course, sin mas
Comment: Correct answer BE
Comment: Answer B
Comment: B, read replica
Comment: Read replica
Comment: B looks correct
Comment: B is the correct answer
Comment: A - Cloudtrail is for API Calls and changes on AWS account. B - Going for athena in S3. - Correct C - Manual work D - Distractor
Comment: Answer B
Comment: Correct answer is B
Comment: B - Amazon Athena is an interactive query service that makes it easy to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL.
Comment: Why there is a "Correct answer" (the green bordered one) at all while most of the time the community thinks (correctly) otherwise?
Comment: why not A?
Comment: Access logs is an optional feature of Elastic Load Balancing that is disabled by default
Comment: Should be C: Public NAT GW in Public Subnet to have access to internet. Private NAT GW is used for VPC or on-prem
Comment: I think the correct is C, because D would require more than just private NAT gateway. Private – Instances in private subnets can connect to other VPCs or your on-premises network through a private NAT gateway. You can route traffic from the NAT gateway through a transit gateway or a virtual private gateway. You cannot associate an elastic IP address with a private NAT gateway. You can attach an internet gateway to a VPC with a private NAT gateway, but if you route traffic from the private NAT gateway to the internet gateway, the internet gateway drops the traffic. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Comment: Public NAT Gateway in public subnets for the internet access https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Comment: Public NAT GW in Public Subnet to have access to internet
Comment: Looks correct
Comment: My vote is for BE
Comment: B - Attach the SPC to the three accounts E - Creates an OU > moves the member accounts to OU > attach the SCP to OU "If you apply an authorization policy (for example, a service control policy (SCP)), to the root, it applies to all organizational units (OUs) and member accounts in the organization." "A" would also affect the one production account, which we clearly don't want. You can "attach an SCP to a root, OU, or account"
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
Comment: Only the non-prods need to be limited.
Comment: According to GPT-4 it's AE: A. Attach the SCP to the root OU for the organization. This approach will apply the SCP to all accounts under the organization, including both nonproduction and production accounts. However, without additional context or actions, this does not meet the requirement to exclude the production account from the restrictions. E. Create an OU for the required accounts. Attach the SCP to the OU. Move the nonproduction member accounts into the new OU. This is the correct approach as it directly addresses the requirement. By creating a separate OU for nonproduction accounts and attaching the SCP to this OU, you can specifically target the policy to only those accounts, effectively exempting the production account from the restrictions.
Comment: AC - same answer https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
Comment: The link you provided says: "If you apply an authorization policy (for example, a service control policy (SCP)), to the root, it applies to all organizational units (OUs) and member accounts in the organization." "A" would also affect the one production account, which we clearly don't want. You can "attach an SCP to a root, OU, or account" https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Comment: From Chat A. Attach the SCP to the root OU for the organization: Attaching the SCP to the root OU ensures that it applies to all member accounts within the organization, including both nonproduction and production accounts. D. Create an OU for the production account. Attach the SCP to the OU. Move the production member account into the new OU: By creating a separate OU for the production account and attaching the SCP to that OU, you can ensure that the SCP only affects the nonproduction accounts while allowing the production account to operate without restrictions.
Comment: I think it's B (directly attach) and E (attach via OU).
Comment: CE should be the correct answer
Comment: I think this question asks about the connection not about authorization, and for a secure S3 connection (e.g. without internet exposure, etc. ) should be a VPC endpoint.
Comment: A VPC endpoint enables customers to privately connect to supported AWS services .
Comment: D is the correct answer.
Comment: A is the correct answer
Comment: Only C is real viable option - Adding Reader replica for handling Read load and RDS Proxy for connections.
Comment: C - Explanation below:
Comment: A - "Lambda function to log state changes" - doesn't help with read/write load. B - ZDR applies to restarts that Aurora performs automatically to resolve error conditions: doesn't help with read/write load. D - Write-around approach: data is always written to the database and the data that is read goes to the cache. Doesn't help with read/write load. C - CORRECT. Even though it doesn't address "write operations", Aurora Replicas to offload read workloads from the primary DB instance. Amazon RDS Proxy allows applications to pool and share connections established with the database, improving database efficiency and application scalability.
Comment: AnswerC. Proxy should help with the problem
Comment: Selected Answer: C RDX proxy to handle timeout issue
Comment: I go with C bc there is no better option
Comment: RDX proxy to handle timeout issue. option C
Comment: I would go for option C
Comment: If you have workloads that leverage both VPCs and on-premises resources, you also need to resolve DNS records hosted on-premises. Similarly, these on-premises resources may need to resolve names hosted on AWS. Through Resolver endpoints and conditional forwarding rules, you can resolve DNS queries between your on-premises resources and VPCs to create a hybrid cloud setup over VPN or Direct Connect (DX). Specifically: Inbound Resolver endpoints allow DNS queries to your VPC from your on-premises network or another VPC. Outbound Resolver endpoints allow DNS queries from your VPC to your on-premises network or another VPC. Reference: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html
Comment: Right to the point!
Comment: AWS <-> On-premises = Route 53 Resolver - Outbound Resolver = From your VPC (AWS) to On-premises or another VPC - Inbound Resolver = From on-premises network or another VPC TO your VPC.
Comment: The reason why i vote on C, because the question mentioned that "The company uses Amazon Route53 as it's DNS service" and did not mention that is using multiple accounts, so it should be the most secure way to just add the record in it's private host zone of it's own account due to dns poisoning concern. Of cause, i totally agree on A if the dns zone owner is in on-premises dns server which reduce the operation efforts.
Comment: C. Create a Route 53 private hosted zone. Associate the private hosted zone with the VPC. This setup allows the application within the VPC to resolve DNS queries using private DNS records, ensuring that the communication remains within the AWS network and is not exposed to the public internet. Associating the private hosted zone with the VPC ensures that only the resources within the VPC can resolve the DNS queries, maintaining a secure environment for application and on-premises service communication. The outbound resolver endpoint and rule would be more relevant if the requirement was for resources within the VPC to resolve DNS queries for domain names that are located in the on-premises network. In that case, the outbound resolver would forward queries from the VPC to the on-premises DNS server for resolution. However, for private DNS communication from the VPC to on-premises services, the private hosted zone is the most secure method.
Comment: Amazon Route 53 Resolver provides DNS resolution for VPCs and on-premises networks
Comment: Amazon Route 53 Resolver provides DNS resolution for VPCs and on-premises networks over a Direct Connect or VPN connection. An outbound resolver endpoint forwards DNS queries from your VPC to your on-premises DNS service. A resolver rule specifies the domain names for the DNS queries that you want to forward (such as example.com), and the IP addresses of the DNS resolvers in your on-premises network. Option C is not suitable because private hosted zones are used to route traffic within a VPC https://aws.amazon.com/blogs/architecture/using-route-53-private-hosted-zones-for-cross-account-multi-region-architectures/
Comment: Should be A "Create a Route 53 Resolver outbound endpoint."
Comment: Looks correct
Comment: B is the correct option
Comment: The Intelligent-Tiering storage class automatically moves objects between two access tiers (frequent access and infrequent access) based on their access patterns, which aligns well with the varying view frequencies of the photos. Storing metadata in DynamoDB allows for efficient querying and retrieval of photo metadata.
Comment: AnswerB Seem to be the best solution from provided
Comment: Store the photos in the Amazon S3 Intelligent-Tiering = Unpredictable scenario
Comment: Correct option: B
Comment: Option B is correct because can use "RequestCountPerTarget" to identify the amount of requests for each EC2 instance. Then use "least outstanding requests algorithm" to route to targets with the lowest number of in progress requests. Option D is wrong because "RequestCount" cannot identify the amount of requests for each EC2 instance. "RequestCount" is for the whole ALB.
Comment: https://aws.amazon.com/about-aws/whats-new/2019/11/application-load-balancer-now-supports-least-outstanding-requests-algorithm-for-load-balancing-requests/
Comment: Option B would be the correct choice
Comment: AnswerB
Comment: Option B
Comment: IMO the correct answer is option D: This is from an earlier version of the AWS documentation on ALB target groups - for some reason they removed this information in the current revision: "Consider using least outstanding requests when the requests for your application vary in complexity or your targets vary in processing capability. Round robin is a good choice when the requests and targets are similar, or if you need to distribute requests equally among targets. You can compare the effect of round robin versus least outstanding requests using the following CloudWatch metrics: RequestCount, TargetConnectionErrorCount, and TargetResponseTime." https://web.archive.org/web/20200426172626/https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm
Comment: The link is just saying that you can view "RequestCount, TargetConnectionErrorCount, and TargetResponseTime" to understand the difference in effect between round robin vs least outstanding requests. It is not the direct answer to this question.
Comment: I think TargetResponseTime is the best indicator for telling is a server is overloaded or not
Comment: distribute the number of requests among instances
Comment: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html To understand the types
Comment: The question is not asking for better performance in response time. It is just simply asking to distribute the number of requests among instances. So B seems more logical.
Comment: The least outstanding requests routing algorithm routes requests to the targets with the lowest number of in progress requests > https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
Comment: D>>> The least outstanding requests routing algorithm routes requests to the targets with the lowest number of in progress requests > https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
Comment: Why not D?
Comment: With Least outstanding requests algorithm, new request will send it to the "target" with least number of outstanding requests. Targets processing long-standing requests or having lower processing capabilities are not burdened with more requests. That's why option B is correct and not option D.
Comment: My vote is for A : https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-usingBudgets.html
Comment: A - describes exactly what is said in this link: "You can use AWS Budgets to enable simple-to-complex cost and usage tracking. Some examples include: (...) Setting a daily utilization or coverage budget to track your RI or Savings Plans. You can choose to be notified through email and Amazon SNS topics when your utilization drops below 80 percent for a given day." https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html
Comment: D - clearly not what the question is asking: "You can track your Savings Plans expirations and upcoming queued Savings Plans in Cost Explorer. You can use Savings Plans alerts to receive advance email alerts 1, 7, 30, or 60 days before your Savings Plan expiration date, or in when a commitment is queued for purchase. These notifications also alert you on the expiration date, and can be sent to up to 10 email recipients." "Savings Plans Expiration Alerts notify you as your existing Savings Plans approach expiration. These alerts can help you easily renew your Savings Plans ."
Comment: https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-alert.html
Comment: AnswerA We can set Savings Plan in AWS Budgets which will notify us if utilization, coverage and costs will be not in set range. https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-usingBudgets.html
Comment: D: https://aws.amazon.com/about-aws/whats-new/2020/11/savings-plans-alerts-now-available-in-aws-cost-management/
Comment: https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-savings-plans-expiration-and-queued-alerts-now-available-in-aws-cost-management/
Comment: Correct answer is A
Comment: A is precisely targeted
Comment: Ny vote going to D. https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-savings-plans-expiration-and-queued-alerts-now-available-in-aws-cost-management/
Comment: A is correct
Comment: Option D...In the Savings Plans Overview page indicate how many days in advance you would like to receive Savings Plans Alerts for Plan's expiration and upcoming queued purchase notifications.
Comment: Option D
Comment: alert subscription will notify u before ending saving plan
Comment: Since we are talking about real-time data (UDP packets) ALB is not a viable solution. You don't need to listen HTTPS, so D is eliminated. If you create a new VPC, you must create link between the old one and this is not mentioned in B. So It is A for me.
Comment: "You can turn on public access to an MSK cluster at no additional cost... To turn on public access to a cluster, first ensure that the cluster meets all of the following conditions: - The subnets that are associated with the cluster must be public. - Unauthenticated access control must be off and at least one of the following access-control methods must be on: SASL/IAM, SASL/SCRAM, mTLS. - ..." https://docs.aws.amazon.com/msk/latest/developerguide/public-access.html
Comment: There is no reference to a NEW VPC being required in the documentation. We can simply configure subnets in the existing VPC.
Comment: AnswerA I need to agree that answer will probably be Option A.
Comment: A is correct
Comment: A, since Kafka is loadbalancing itself. - https://dattell.com/data-architecture-blog/load-balancing-with-kafka/#:~:text=Load%20balancing%20with%20Kafka%20is,partitions%20while%20preserving%20message%20ordering. B - why create new VPC? C / D - Kafka is loadbalacing itself, also NLB can't handle HTTPS.
Comment: Option A
Comment: D looks more secure over existing on-prem to AWS connection -Transfer Family SFTP internal server in two Availability Zones. -Use Amazon S3 storage. -Use a Transfer Family managed workflow to invoke the Lambda function"
Comment: If the legacy application needs to ingest customer order files from an on-premises ERP system and upload them to an SFTP server, an internet-facing AWS Transfer Family SFTP server would be the appropriate choice. In this scenario, the SFTP server needs to be accessible from the internet to facilitate the file transfer between the on-premises system and AWS. Therefore, an internet-facing server is required to securely receive the files.
Comment: "The company already has an AWS account that has connectivity to the on-premises network." Internal Server.
Comment: Answer D
Comment: "order files from an on-premises enterprise resource planning (ERP)" - Therefore Internal Endpoint is enough, no need for Internet-facing, although Internet-facing also handles on-prem connections as well, but "most secure". Even tho we are talking about SecureFTP.... Very bad wording of the question... :( Definitely S3 against EFS, so D should be the answer...
Comment: Also: With managed workflows, you can kick off a workflow after a file has been transferred over SFTP
Comment: Correct answer is A because must support integration with existing erp system we need to choose sftp internal-facing
Comment: Answer is D . Both A&D are right but the question says it must support integration with existing erp system. I believe you can use transfer family for the existing job onprem as well to check for files.
Comment: has an AWS account that has connectivity to the on-premises network.
Comment: The company already has an AWS account that has connectivity to the on-premises network. So no need internet.
Comment: I would go in D as it's internal network.
Comment: I think A makes more sense
Comment: A is the correct option
Comment: C cover requirement: The solution must keep the data processing on premises
Comment: I would go for option C, as data processing has to be done on premise.
Comment: Answer C
Comment: Only solution to keep the processing on-prem.
Comment: Create an Amazon EMR Cluster: With the data now available in Amazon S3, the company can create an Amazon EMR cluster for data processing. EMR provides scalable Hadoop and Spark clusters that can process data stored in S3, enabling the company to leverage cloud-based processing resources while still keeping the data processing on premises.
Comment: Selected response : C
Comment: Amazon FsX for NetAPP ONTAP feature: Multi-protocol access to data using the Network File System (NFS), Server Message Block (SMB), and Internet Small Computer Systems Interface (iSCSI) protocols
Comment: option C .... SMB and NFS storage protocols ->S3 file gateway
Comment: "S3 File Gateway is used for on-premises data intensive applications that need file protocol access to objects in S3. " https://aws.amazon.com/storagegateway/file/s3/
Comment: The company is MIGRATING data from on-premises to AWS. Amazon FSx for NetApp ONTAP offers high-performance file storage that's broadly accessible from Linux, Windows, and macOS compute instances via the industry-standard NFS, SMB, iSCSI, and NVMe-over-TCP protocols. https://aws.amazon.com/fsx/netapp-ontap/features/
Comment: Amazon FSx for NetApp ONTAP offers high-performance file storage that's broadly accessible from Linux, Windows, and macOS compute instances via the industry-standard NFS, SMB, iSCSI, and NVMe-over-TCP protocols. https://aws.amazon.com/fsx/netapp-ontap/features/ "S3 File Gateway is used for on-premises data intensive applications that need file protocol access to objects in S3. " https://aws.amazon.com/storagegateway/file/s3/
Comment: Answer B
Comment: I think it is "C" Not "B" - The question never indicates the company is using "NetApp ONTAP file systems", so I am not sure what it means by "Migrate the data to the FSx for ONTAP volume". Please correct if misunderstood. "C" clearly indicates how to migrate the data to S3, the S3 Intelligent-Tiering addressed the access pattern in the question and you can SMB/NFS mount S3 bucket https://docs.aws.amazon.com/filegateway/latest/files3/using-smb-fileshare.html https://docs.aws.amazon.com/filegateway/latest/files3/GettingStartedAccessFileShare.html
Comment: FSx for ONTAP support NFS and SMB Protocol, even AWS Storage Gateway Amazon S3 File Gateway support them but it is used to connect on premises devices to file on s3, not to connect ec2 instances in the same aws region
Comment: Amazon FSx for NetApp ONTAP provides fully managed shared storage in the AWS Cloud with the popular data access and management capabilities of ONTAP. Move workloads running on NetApp or other NFS/SMB/iSCSI servers to AWS without modifying application code or how you manage data. And FsX for NetAPP ONTAP support "Reducing storage costs with automatic and intelligent storage tiering." https://aws.amazon.com/tw/fsx/netapp-ontap/faqs/#product-faqs#netapp-ontap-faq#reducing-storage-costs-with-automatic-and-intelligent-storage-tiering
Comment: it's C
Comment: B - FSx for ONTAP support SMB and NFS
Comment: Amazon FsX for NetAPP ONTAP feature: Multi-protocol access to data using the Network File System (NFS), Server Message Block (SMB), and Internet Small Computer Systems Interface (iSCSI) protocols Option C: make no sense I see it as a distractor
Comment: Both B and C works, but it seems like C has a least operational overhead
Comment: The company will access the remaining data infrequently."
Comment: https://www.amazonaws.cn/en/storagegateway/faqs/#:~:text=The%20Amazon%20S3%20File%20Gateway,be%20directly%20accessed%20in%20S3.
Comment: It's B, option C makes no sense. 1. "Migrate the data to the S3 bucket using an AWS Storage Gateway Amazon S3 File Gateway." -> Nothing about running the gateway to access the files via SMB and NFS afterwards. 2. Even if you ignore this, the S3 File Gateway requires a virtual appliance to be deployed (on EC2 in this case), which contradicts the "LEAST operational overhead" requirement.
Comment: Option C looks correct. "The company will access a portion of the data routinely. The company will access the remaining data infrequently."
Comment: option B
Comment: C is correct
Comment: Option A and D do not support SMB and NFS file system . Option b looks correvt
Comment: Option with S3 usage looks corrcet
Comment: Microservices using ECS
Comment: Monolith -> Microservices = ECS.
Comment: Sure 100%
Comment: Microservices using Elastic Container Service is correct
Comment: C is correct
Comment: B will not help spot instances provide cost savings but using it for a stateful task isn't right cause spot instances can be interrupted
Comment: Correct answer but incorrect reasoning. Spot fleet includes on-demand AND spot instances to provide the desired capacity.
Comment: Lambda looks like a better option
Comment: Lambda serverless, scalable, minimal infrastructure, handling hundreds of requests per second
Comment: A: auto-scaling of EC2 instances - Lot of overhead + Infra B: The company selected one component of the web application to test as a microservice. The component supports hundreds of requests each second. > lastic Beanstalk is a bad choice if you need worker processes. The whole point of a worker process is to perform a task in the background without slowing down your main web app. But Elastic Beanstalk doesn't support this option in a scalable way. Also, they want to test just 1 selected microservice and I think it's a bit of overkill to do it using Elastic Beanstalk. Happy to be challenged though! C: self-managed EC2 instances > infra + operational overhead D: Lambda supports Python, microservice should be quicker than 15 mins, worst case scenario the test will fail.. (that's the purpose tests are conducted for anyway..) I'd go for D
Comment: microservice => EKS, ECS
Comment: C is the correct answer. The best way to deploy microservice is to use container-based service
Comment: "Maintain nodes yourself with self-managed nodes" https://docs.aws.amazon.com/eks/latest/userguide/worker.html
Comment: Microservices doesn't automatically mean ECS or EKS. Read the question again: "Serverless" clearly contradicts "self-managed EC2 instances". D is the only option that fits the criteria.
Comment: Best answer is C. The application is a large-scale we app as mentioned in the question.
Comment: You cannot have 'minimal infrastructure and minimal operational support' with 'Auto Scaling groups of self-managed EC2 instances.'
Comment: I mean B for Elastic Beans Stalk not C. EBS is the best solution for running large-scale application.
Comment: C is the correct answer. The best way to deploy microservice is to use container-based service such as EKS or ECS. So C is great
Comment: Using ECS or EKS involves managing cluster and ec2 which will increase the infrastructure and operational overhead compared to lambda which is serverless.
Comment: EBS for minimal infra maintenance
Comment: Option A
Comment: A is the best solution
Comment: "You can use AWS Direct Connect gateway to connect your Direct Connect connection over a transit virtual interface to the VPCs or VPNs that are attached to your transit gateway. You associate a Direct Connect gateway with the transit gateway. Then, create a transit virtual interface for your AWS Direct Connect connection to the Direct Connect gateway." https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html
Comment: Turn on the transit gateway's route propagation feature.
Comment: https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html
Comment: transit gateway -> hub and spoke
Comment: option C....Default Host Management Configuration creates and applies a default IAM role to ensure that Systems Manager has permissions to manage all instances in the Region and perform automated patch scans using Patch Manager.
Comment: C is the answer
Comment: "The Default Host Management Configuration setting allows AWS Systems Manager to manage your Amazon EC2 instances automatically as managed instances. Default Host Management Configuration makes it possible to manage EC2 instances without your having to manually create an AWS Identity and Access Management (IAM) instance profile. Instead, Default Host Management Configuration creates and applies a default IAM role to ensure that Systems Manager has permissions to manage all instances in the AWS account and AWS Region where it's activated."
Comment: https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-default-host-management-configuration.html
Comment: i think A
Comment: So is C same as A, but automated?
Comment: C is fine
Comment: C is a better option
Comment: Correct answer A
Comment: "Attach the new IAM role to the EC2 instances and the existing IAM role" - You can't attach multiple policies to an EC2 instance. So A is wrong.
Comment: Refer to https://www.examtopics.com/discussions/amazon/view/109702-exam-aws-certified-solutions-architect-associate-saa-c03/
Comment: AnswerB Using of Kubernetes Cluster Autoscaler seems to be the best solution here
Comment: When the workload increases and existing nodes reach maximum capacity, the Cluster Autoscaler detects the need for additional nodes and requests them from the underlying AWS infrastructure.
Comment: Bcorrect
Comment: B is the correct answer. The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in your cluster when pods fail or are rescheduled onto other nodes. The Cluster Autoscaler uses Auto Scaling groups
Comment: option B.
Comment: Kubernetes Cluster Autoscaler looks correct
Comment: B - No brainer.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html
Comment: Optimize multipart uploads to reduce costs associated with storing incomplete multipart upload parts. Ensure that multipart uploads are completed and the parts are assembled into complete objects in a timely manner to avoid unnecessary storage costs.
Comment: when primary concern is cost and the data transfer multipart upload may be the more cost-effective than S3 transfer acceleration. So switching to s3 TA is won't be reasonable.
Comment: Option B is correct
Comment: Option B
Comment: Why are people voting for C? PostgreSQL is a relational DB. DynamoDB is NoSQL. It makes no sense
Comment: its bezos with his alt accounts.
Comment: Refer to https://www.examtopics.com/discussions/amazon/view/53854-exam-aws-certified-solutions-architect-associate-saa-c02/
Comment: Specific to Redis, ElastiCache lets you “scale in” or “scale out” both reads and writes. Cluster mode offers added shard support, enabling write scaling. https://aws.amazon.com/blogs/database/building-a-real-time-gaming-leaderboard-with-amazon-elasticache-for-redis/
Comment: I confuse, Is DAX working with RDS?
Comment: The answer C is not making any sense with "Deploy Amazon DynamoDB Accelerator (DAX) in front of the existing DB instance.", because AWS DynamoDB is a DBaaS.
Comment: AnswerD ElastiCache is a fully managed, in-memory caching service that provides microsecond read and write latencies that support flexible, real-time use cases. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/creating-elasticache-cluster-with-RDS-settings.html
Comment: Beside DAX is for DynamoDB and I think it will not work with RDS
Comment: Amazon ElastiCache for Redis for RDS
Comment: " writing updates" so it shoud be DAX.
Comment: Vote for C (DAX) as ElastiCache for Redis cluster only helps on read operation but not white.
Comment: Vote for C (DAX) as ElastiCache for Redis cluster only helps on read operation but not write operation.
Comment: Performance >> Amazon ElastiCache for Redis cluster
Comment: Yeah, but this is an online game that need to update everything instantly so i don't think that caching is the right method here think about it, you are making movments in the online game its like loading new data all the time, so each time you move you load the cache for next time usage. what if you dont need to use it again? i dont think elasticache is the right method here so it leave us with DAX what do you think?
Comment: i agree with DAX, but how it can be deploying in front of DB instance? Since that is a DBaaS.
Comment: D looks correct
Comment: D looks correct
Comment: Looks correct
Comment: https://aws.amazon.com/about-aws/whats-new/2023/03/amazon-dynamodb-table-deletion-protection/ Deletion protection is now available for Amazon DynamoDB tables in all AWS Regions. DynamoDB now makes it possible for you to protect your tables from accidental deletion when performing regular table management operations. When creating new tables or managing existing tables, authorized administrators can set the deletion protection property for each table, which will govern whether a table can be deleted.
Comment: Option B and D talks about recovering but not preventing. A is tooooo much work
Comment: B involves more operations.
Comment: Option C
Comment: B is the correct one because: "A company has an on-premises data center that is running out of storage capacity". So when they keep data on-premis and do the backup to S3 they'll run out of data and this is not their purpose.
Comment: B. Deploy AWS Storage Gateway using cached volumes. Use Storage Gateway to store data in Amazon S3 while retaining copies of frequently accessed data subsets locally. AWS Storage Gateway's cached volumes let you use Amazon S3 as your primary data storage while retaining frequently accessed data locally in your storage gateway. Cached volumes minimize the need to scale your on-premises storage infrastructure, while still providing your applications with low-latency access to their frequently accessed data. All data transferred between your gateway and AWS storage is encrypted for security. You can also save on data transfer costs as AWS Storage Gateway compresses all data transferred between the gateway and AWS, allowing you to store more data in AWS while reducing your data transfer costs.
Comment: I vote "C" because Question doesn't mention to access frequent data. If they want access frequent data, I will vote "B" with cached volume.
Comment: you don't fool me bezos boy
Comment: AnswerB I think B answer is the best option here. We will store only data which are frequently accessed and all other we will sent to the cloud. So we will have access to all data but hence most frequently accessed data will be stored in On-Premises Cache we will not pay a lot of additionally $$ for data transfer if any.
Comment: C is the correct. answer
Comment: 1- "The company wants to migrate its storage infrastructure to AWS" ->> B as data will be migrated to AWS. 2- "The solution must allow for immediate retrieval of data at no additional cost." ->> B as data will be stored in S3 Standard storage class which provide immediate data retrieval
Comment: immediate retrieval of data → shoud have full data set on-premises => stored volumes AWS Storage Gateway
Comment: B - as the company is migrating their data to AWS so data has to be stored in the cloud.
Comment: C>>> Cached Mode: In this mode, your primary data resides in Amazon S3, while frequently accessed data is cached locally for low-latency access. Stored Mode: Here, your entire dataset is stored locally, allowing low-latency access on premises. Simultaneously, the data is asynchronously backed up to Amazon S3.
Comment: How does that address the fact the company is "running out of storage capacity"?
Comment: D -> It takes One month to set up AWS Direct Connect setup A -> No sense as it talks nothing about On-Prem B -> Cached volume only stores frequently access data On-Prem, But requirement tells "Data" so we assume it tells All data C -> Correct, as Stored volumes stores everything in Storage Gateway On-Prem while asynchronously backing up to the cloud
Comment: D: It never said one month would be a problem.. Question doesn't state a matter of urgency, but it still stores the data on-prem, and synchronizes to AWS. C: The same issue as D. Stores data locally, but our on-prem storage is full. Thats why the company wants cloud. A: Has retrieval costs.
Comment: i was voting for C, but C doesnt solve on prem out of capacity issue.
Comment: option C... data being accessible through stored volume reduces bandwidth cost and provides immediate retrieval of data.
Comment: Option C, as it makes all the data available for low-latency access.
Comment: Not A: Only handles Dynamic scaling, not pattern-based/predictive scaling. B: Both Predictive and dynamic Not C: Manual version of predictive, lacks live circumstances.. Not D: The question doesn't talk about cool down period...
Comment: https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/
Comment: By configuring dynamic scaling with target tracking, the company can automatically adjust resources based on the forecasted demand while also responding to live changes in utilization
Comment: Option B
Comment: Option A
Comment: AnswerC After topic reconsideration I will go with Aurora autoscaling To meet your connectivity and workload requirements, Aurora Auto Scaling dynamically adjusts the number of Aurora Replicas (reader DB instances) provisioned for an Aurora DB cluster. Aurora Auto Scaling is available for both Aurora MySQL and Aurora PostgreSQL. Aurora Auto Scaling enables your Aurora DB cluster to handle sudden increases in connectivity or workload. When the connectivity or workload decreases, Aurora Auto Scaling removes unnecessary Aurora Replicas so that you don't pay for unused provisioned DB instances. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html
Comment: repeated reads = perfect scenario for CACHING. How adding more reader instances will "alleviate the effect of repeated reads on the DB cluster"?
Comment: AnswerA
Comment: A. Although Redis is not typically cheap, the question statement clearly shouts for a cached solution, which is Redis... Also, that's the only long-term solution, as we don't know anything about the volumes, scale of trends, etc...
Comment: "repeated read statements" -> Cache layer
Comment: The question says, "The operations that cause the increase in DB cluster usage are all **repeated read statements** that are related to delivery details." - Read statements mean we can cache the results - hence, we need No read-replicas; we need only a cache layer to improve the performance.. Also, Adding read replicas costs money. The requirement is to meet them MOST cost-effectively
Comment: DynamoDB by default provides eventual consistency for read operations, which means that a query may not reflect the most recent data changes immediately after an update. Instead, it may take some time for the data to propagate across all replicas in the DynamoDB global table. To ensure that read operations return the latest data and address the issue of stale data being returned to users, the solutions architect should recommend switching the read consistency level from eventually consistent reads to strongly consistent reads.
Comment: Both tables and LSIs provide two read consistency options: eventually consistent (default) and strongly consistent reads. 1) Eventually Consistent Reads Eventually consistent is the default read consistent model for all read operations. When issuing eventually consistent reads to a DynamoDB table or an index, the responses may not reflect the results of a recently completed write operation. If you repeat your read request after a short time, the response should eventually return the more recent item.
Comment: 2) Strongly Consistent Reads Read operations such as GetItem, Query, and Scan provide an optional ConsistentRead parameter. If you set ConsistentRead to true, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful. Hence it is C A) Read-replicas are Async again, Which will persist the same problem. B) Indexing will further cause latency, this has nothing to do with the question
Comment: Option C
Comment: Option B
Comment: It's probably still B, but waf can't be attached directly to ec2's
Comment: protect the application and the database from SQL injection and other web-based attacks. -> WAF
Comment: SQL injection -> WAF
Comment: A -> SCPs are not for monitoring or logging B-> correct After you enable the RDS Protection feature, GuardDuty immediately starts monitoring RDS login activity from Aurora databases in your account. GuardDuty continuously monitors and profiles RDS login activity for suspicious activity, for example, unauthorized access to Aurora database in your account, from a previously unseen external actor.
Comment: AnswerB https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_BestPractices.Security.html Amazon GuardDuty is a threat detection service that helps protect your accounts, containers, workloads, and the data within your AWS environment. Using machine learning (ML) models, and anomaly and threat detection capabilities, GuardDuty continuously monitors different log sources and runtime activity to identify and prioritize potential security risks and malicious activities in your environment. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/guard-duty-rds-protection.html
Comment: malicious activity=gurd duty
Comment: B is the correct answer. Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your Amazon Web Services accounts, workloads, and data stored in Amazon S3.
Comment: Option B
Comment: "If you want to set up a Direct Connect to one or more VPC in many different regions (same account), you must use a Direct Connect Gateway."
Comment: CloudHub is a VPN (encrypted) connection, so it goes over the public Internet., Whereas DirectConnect is Private (but not encrypted). So CloudHub is not suited for this useCase
Comment: option D
Comment: Changing to Option D for simpler implementation.
Comment: sure "Andy"
Comment: Option A
Comment: requirement -1: "Stream + process in order + Minimum Overhead" = Kinesis Data Stream + Lambda requirement-2: "Highly available database + Min Management overhead" = DynamoDb Setting Up Ec2 instance or MultiAZ DB = overhead
Comment: Option A
Comment: AnswerA
Comment: Even though it looks like SQS, but EC2 and Multi-AZ DB fail when it comes to minimal operational overhead.
Comment: easy one: mobile game ->> DynamoDB
Comment: The main Use case of S3 same region replication is "log aggregation, live replication between production and test accounts".
Comment: Option B
Comment: Needs to be B
Comment: To keep replication in SYNC across all three regions, we use Bi-directional. Multi-Region Access Point for video streaming and uploads. -> uploads to nearest Low latency region and Bi-directional replication will keep other two regions in SYNC this reducing the upload and streaming latency
Comment: For confirmation purposes: https://aws.amazon.com/s3/features/multi-region-access-points/
Comment: They are simply trying to replicate to a new S3 bucket. I don't see why it needs to be bidirectional. Also, since the problem assumes that the content developer with permission is the one uploading, it seems like there needs to be a way to centralize the upload without modifying the application.
Comment: Since developer upload video to us-east-2, by configuring one-way replication directly from us-east-2 to eu-west-2 and from us-east-2 to ap-southeast-1, you ensure that each region has the latest data without additional replication hops.
Comment: AnswerCE From my understanding Video uploads can happen near new regions hence to speed up that operation we need to upload to nearest region, hence I would choose option E, and for the same reason we need to be able to replicate data from any of new region to old one and oposite, hence we we need bidirectional (two-way) replication
Comment: FEWEST changes to the application D -> MRAP can upload the appropriate S3 bucket C -> two-way -> to worry about anything obs: I believe this question dubious, amphibological
Comment: There is no information where the upload should be performed. If files will be uploaded to first region then: AD because: A -> content uploaded to the primary bucket in us-east-2 is automatically replicated to the other regions, minimizing latency for users accessing content near those regions. D -> uploads needs to be performed to the first region only and accessed to remaining two Otherwise CE
Comment: Correct answer CE
Comment: Cloudfront is for reading not for uploading Option B
Comment: Question says - " LOWEST latency for content uploads" Hence Use S3 Transfer Acceleration for the uploads.
Comment: Cloudfront can also upload data, not just for caching content
Comment: Sorry, for this scenario, i believe that B its the correct
Comment: B is the answer
Comment: option D. Upload and store content in Amazon S3 in the Region that is closest to the user. Use multiple distributions of Amazon CloudFront. This solution ensures low-latency uploads by storing content in the nearest S3 region and provides fast access to users by distributing content through CloudFront edge locations.
Comment: CloudFront does support upload acceleration https://aws.amazon.com/blogs/aws/amazon-cloudfront-content-uploads-post-put-other-methods/
Comment: Option D
Comment: Amazon S3 Transfer Acceleration utilizes Amazon CloudFront's globally distributed edge locations to accelerate content uploads to Amazon S3.
Comment: S3TA is acturally using cloudfront's infrastructure. So, yes B. Which is just an optimized solution for cloudfront itself.
Comment: Option D Regional S3 Buckets: Storing content in S3 buckets located in the same Region as the user minimizes the physical distance the data needs to travel during upload, reducing latency. CloudFront Distributions: CloudFront is a content delivery network (CDN) that caches content in edge locations around the world. By creating multiple CloudFront distributions with edge locations closest to users, the content can be served with minimal latency for downloads.
Comment: Option D
Comment: option B... S3 transfer acceleration for LOWEST latency for content uploads. question is not asking for low latency for content retrieval. Happy to be corrected
Comment: "message filtering" = SNS
Comment: LEAST operational overhead -> B better than A
Comment: AnswerA Hence EventBridge is a solution to handle events and we need to handle messages I believe option A is the best solution here
Comment: https://aws.amazon.com/blogs/compute/capturing-client-events-using-amazon-api-gateway-and-amazon-eventbridge/
Comment: The main issue with B is that with Eventbrige, you can only define up to five targets for each rule. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html
Comment: B: EventBridge reacts to events, not requests or messages. C: I don't think so, but I don't know MSK well enough. D: You can add a filter so that your function only processes Amazon SQS messages containing certain data parameters. but it will still receive, so I assume it's not what the question asks for. Only A remains... But it still misses steps plus we are looking for the Least ops overhead.. I am confused..
Comment: Eventbridge + lambda is two services, sns + sqs + lambda is 3. Both can filter, but the config involved in eventbridge > lambda is easier
Comment: SNS provides built-in message filtering. SNS -> SQS -> Lambda = very common Fanout Scenario
Comment: Upload and store content in Amazon S3 in the Region that is closest to the user. Use multiple distributions of Amazon CloudFront. This approach ensures that uploads are quick, taking advantage of the geographical proximity of S3, while still leveraging CloudFront for efficient content delivery outside the local region if necessary. The local nature of the content consumption aligns with storing content in the closest region to the user, addressing the requirement that 90% of the content is consumed within the AWS Region where it is uploaded.
Comment: Option B - Eventbridge allow routing event from source to dest or multi dest you want
Comment: EventBridge rules can filter messages based on, content, attributes, or patterns
Comment: A because of SNS
Comment: I'd go with D Multiple targets but target Lambda functions the ability to receive only the messages the functions need, so gateway should send to specific SQS so specific lambda can process that message. With SNS you send to all at once, so lambdas will get the messages they can't process. Correct me if I'm wrong.
Comment: multiple target, message filtering = SNS
Comment: to multiple target = SNS, EventBridge. Also, SNS has to use SQS to send filtered content, and Lambda has to poll the SQS to get the message, which is clearly an Overhead. Meanwhile, EventBridge can invoke a Lambda function, which reduces the Operational Overhead.
Comment: There is no SNS in B.
Comment: option A.. SNS message filtering
Comment: Option A
Comment: A seems correct here. https://aws.amazon.com/blogs/storage/encrypting-objects-with-amazon-s3-batch-operations/
Comment: S3 inventory list has "Encryption status" field so you can use this to filter the unencrypted objects. and use S3 batch to encrypt it with SSE-C key. AWS Usage report does not provide details about encryption status of individual objects
Comment: AnswerA
Comment: A is the answer
Comment: option B.... S3 Inventory report to check for unencrypted objects in s3 and then using Batch operation.
Comment: The solution must encrypt existing unencrypted objects. Batch will do that.
Comment: Option B
Comment: Option A
Comment: A -> Correct as we need to route to a Company in public network. B -> No, because it routes only within one or more VPC C -> Added as a distractor D -> Inbound resolver is for traffic from On-Prem to VPC
Comment: Hello Billaranga, I just bought this examtopics. My exam is on Jun 9th. Did we get questions from exam topics? How was the exam?
Comment: A is the answer https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html
Comment: option A
Comment: Option A
Comment: AppConfig useCase = You can use AWS AppConfig to deploy configuration data stored in the AWS AppConfig hosted configuration store, AWS Secrets Manager, Systems Manager Parameter Store, or Amazon S3. So B and C are out. use RDS to store credentials is not a good practise. So D is out. Ans is A
Comment: Credentials= secrets Manager
Comment: Amazon RDS creates an SSL certificate and installs the certificate on the DB instance when the instance is provisioned. So it is AWS provided.
Comment: AnswerD
Comment: Even if IAM database authentication is enabled, clients still need to download and configure the AWS-provided root certificate to ensure a secure connection using SSL/TLS encryption. Without configuring the certificate, communication may not be fully encrypted, even with IAM authentication enabled. https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html
Comment: That's not in any of the answers - "Provide the certificates in all connections to the RDS instance." this doesn't make sense with option D - it's not saying configure to trust the CA. Answer can only be option A. Your link includes this "Optionally, your SSL/TLS connection can perform server identity verification by validating the server certificate installed on your database.". This you don't actually need to trust the using CA and can configure the app that way - the traffic is still encrypted though.
Comment: A https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
Comment: Optiona A: IAM database authentication provides the following benefits: Network traffic to and from the database is encrypted using Secure Socket Layer (SSL) or Transport Layer Security (TLS). For more information about using SSL/TLS with Amazon RDS, see Using SSL/TLS to encrypt a connection to a DB instance or cluster.
Comment: Option D
Comment: A for sure. The same question was in "AWS Certified Solutions Architect Associate Practice Test 3" on Udemy. There was an explaination that NLB needs to be before ALB because only NLB can have static IP.
Comment: AnswerA
Comment: A - correct (Static ip can thereafter be used for client whitelisting) Using a Network Load Balancer instead of a Classic Load Balancer has the following benefits: Support for static IP addresses for the load balancer. https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
Comment: Option A Please look into the below for detailed explaination https://www.scalefactory.com/blog/2021/12/13/aws-network-load-balancers-new-features/img/previously-firewall-egress.png
Comment: Option C
Comment: B -> Application Load Balancer cannot be assigned an Elastic IP address (static IP address). C -> Its DNS after all, "Associated elastic IP" is what IP? Makes no sense D -> "If you require a persistent public IP address that can be associated to and from instances as you require, use an Elastic IP address instead." PUBLIC IP of an EC2 is not persistent, although we can give an Elastic Ip, Using EC2 in front of a Load Balancer is tooooo much. What if it gets a million request? So to scale that EC2 you use another LB and an ASG>? This makes no sense A is correct because a NLB can have an elastic IP and we can use this in our firewall as per the use case
Comment: Setting up an EC2 instance with a public IP address to act as a proxy in front of the load balancer allows clients with restricted IP access to connect to the web service. The EC2 instance can handle IP address whitelisting and proxy requests to the ELB load balancer, ensuring that only authorized clients can access the service. This solution provides flexibility and control over access while leveraging the scalability and availability benefits of ELB.
Comment: Is this ChatGPT answer? Can you provide the AWS documentation link?
Comment: Option C
Comment: is there any valid justification for opting C? Glad to be informed, as these questions are tricky to answer.
Comment: My inclination is for Option D, but not 100 % sure
Comment: A. Enable and configure enhanced networking on each EC2 instance. Enhanced networking provides higher bandwidth, higher packet per second (PPS) performance, and consistently lower inter-instance latencies. C. Run the EC2 instances in a cluster placement group. A cluster placement group is a logical grouping of instances within a single Availability Zone. This configuration is recommended for applications that need low network latency, high network throughput, or both.
Comment: AC Use of Placement Groups: Utilize EC2 Placement Groups to ensure that instances are physically located close to each other within the same Availability Zone. This reduces the latency between instances by minimizing the distance data needs to travel. Selection of EC2 Instance Types: Choose EC2 instance types optimized for low-latency networking, such as instances with enhanced networking capabilities like Elastic Network Adapter (ENA) or instances that support Amazon EC2 Nitro System. These instances provide high throughput and low latency networking performance.
Comment: To reach speeds up to 10 Gbps between instances, launch your instances in a cluster placement group with the enhanced networking instance type. These instance types are placed physically close to each other. Instance types that are close to each other further reduces latency and improves transfer speeds.
Comment: what's AM?
Comment: option C & E. Option A is not viable as ..EC2 provides enhanced networking capabilities using single root I/O virtualization (SR-IOV) only on supported instance types.
Comment: C'mon, EBS is storage. The question does not deal with the storage solutions. Its a distractor...
Comment: option E... EBS–optimized instance uses an optimized configuration
Comment: Correct option should be CD
Comment: AWS DataSync is a data transfer service that simplifies, automates, and accelerates moving and replicating data between on-premises storage systems and AWS storage services over the internet or AWS Direct Connect. DataSync can transfer your file data, and also file system metadata such as ownership, time stamps, and access permissions. In DataSync, a location for Amazon FSx for Windows is an endpoint for an FSx for Windows File Server. You can transfer files between a location for Amazon FSx for Windows and a location for other file systems. For information, see Working with Locations in the AWS DataSync User Guide. DataSync accesses your FSx for Windows File Server using the Server Message Block (SMB) protocol.
Comment: Does Fsx support SMB? I read prior posts that it only ONTAP supports SMB
Comment: Option C
Comment: AnswerC
Comment: AWS Storage Gateway provides a standard set of storage protocols such as iSCSI, SMB, and NFS, which allow you to use AWS storage without rewriting your existing applications.--->A is not complete describe, so A is out. https://aws.amazon.com/storagegateway/faqs/?nc=sn&loc=6 Only FSx for NetApp ONTAP and FSx for Windows File Server support SMB Protocol. --->B is out. https://aws.amazon.com/tw/fsx/when-to-choose-fsx/ AWS Direct Connect is more expensive than AWS DataSync.--->D is out C is the correct answer.
Comment: Correct Anwer is C As most of the data is unstructured, and the company's file storage consists of SMB-based storage types from multiple vendors which is commonly a Windows-Linux file-sharing type so FSx for Windows File Server file systems completely meets the solution.
Comment: Option C since its SMB (windows) , and low operational effort so DataSync over Direct Connect
Comment: https://docs.aws.amazon.com/datasync/latest/userguide/create-fsx-location.html
Comment: option A below are the links to check both parts of option A. https://docs.amazonaws.cn/en_us/AmazonCloudWatch/latest/monitoring/cloudwatch_crossaccount_dashboard.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html#Unified-Cross-Account-SetupSource-SingleTemplate
Comment: "If you have multiple Amazon accounts, you can set up CloudWatch cross-account observability and then create rich cross-account dashboards in your monitoring accounts. You can seamlessly search, visualize, and analyze your metrics, logs, and traces without account boundaries." Nice catch!
Comment: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html
Comment: It's C
Comment: https://docs.amazonaws.cn/en_us/AmazonCloudWatch/latest/monitoring/cloudwatch_crossaccount_dashboard.html
Comment: Option A
Comment: Option B
Comment: There was option from disttribution Security Tab ==> Request logs for the specified time range where someone could target an IP address and block it - which action won't do more than creating a block rule under the associated Web ACL- but function has vanished, i don't ask me why. So the only feasable option in WEBACLv2 is to go for an Ipset and ad a WebACL ip match block condition. I really liked the option A the first time i experimented it.
Comment: in WAF you can define Web ACL (Web Access Control List) Rule: IP Set: up to 10,000 IP addresses – use multiple Rules for more IPs
Comment: You only need to block an IP. And Cloudfront is the first layer
Comment: The AWS WAF IP set match statement inspects the IP address of a web request against a set of IP addresses and address ranges. Use this to allow or block web requests based on the IP addresses that the requests originate from
Comment: Option B
Comment: c--> Regardless of how you provision users, IAM Identity Center redirects the AWS Management Console, command line interface, and application authentication to your external IdP. IAM Identity Center then grants access to those resources based on policies you create in IAM Identity Center https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html#provisioning-when-external-idp
Comment: Option C https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html
Comment: https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html#provisioning-when-external-idp
Comment: Option C
Comment: AnswerC We need identity-based policy and if we will compare System Admin and Administrator Access policy it clear that SysAdmin have is allowing for limited amount of actions, where Admin Access simple allow for all actions. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SystemAdministrator.html
Comment: (A & D) eliminated. Resource-based policies are attached to a resource NOT an IAM user, group, or role. (B) eliminated. SystemAdministrator has fewer permissions than AdministratorAccess.
Comment: The question says "full access to AWS services and resources in the AWS account" and "created an IAM user group." You can see it is identity-based policy, not resource-based.--->A and D are out. SystemAdministrator: Allow 28 of 412 services.--->B is out. AdministratorAccess: Allow 412 of 412 services.--->C is the correct answer. If you are curious about what a policy can allow for, just log in you AWS account and go to IAM-policies to find out.
Comment: C is the correct answer
Comment: C>>>https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html
Comment: C>>>https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html
Comment: C looks correct
Comment: Option C
Comment: "As its name suggests, exactly-once semantics means that each message is delivered precisely once. The message can neither be lost nor delivered twice (or more times)." - SNS doesn't provide exactly-once delivery. Thus, we need SQS. - To achieve "least amount of intra management", we go with Lambda for compute layer.
Comment: AnswerAD, SQS FIFO will guarantee exactly one time execution for each operation. The problem is with processing as we do not know if whole process will be closed in 15 min (TTL for Lambda). I'm choosing Lambda as it is natural thing for Payment procesing in AWS but I'm not 100% sure
Comment: Lamdba+SQS FIFO
Comment: someone please explain why the combination of D and E is not the correct?
Comment: because qn says 'least amount of infrastructure management'. E is not.
Comment: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues-exactly-once-processing.html
Comment: option A for payment processing. option D for exactly once delivery.
Comment: CD IS THE BEST ANSWER
Comment: a and d
Comment: "... an on-premises file system receives" = file system > EFS. SFT in AWS = AWS Transfer family Even though D works, that would require changes in the current architecture.
Comment: AnswerA Option A and D will work, but taking into consideration requirements I would go with A
Comment: File system = efs, fsx, ....
Comment: Option D, I'm not 100% sure.. Always prefer S3 over EFS
Comment: "... an on-premises file system receives" = file system > EFS.
Comment: A should be enough. EFS can be mounted to ASG directly, and there is no need to use S3 in the middle.
Comment: I think the ans is A as well, option D require "Modify the application" which is not "minimize operational effort"
Comment: Option D
Comment: Option D
Comment: The Answer should be A not D because ... Modify the application to pull the batch files from Amazon S3 to an Amazon EC2 instance for processing.--Why we need to do this when we can move the file directly to EFS in EC2 system AWS Transfer Family now also supports file transfers to Amazon Elastic File System (Amazon EFS) file systems as well as Amazon S3.
Comment: trasnfer + S3 = HA, scheduled scaling = resilient
Comment: I'm not 100% sure, but D looks like the right flow to me
Comment: I agree on a professional level, that's will make the company save money, that is the only things company care about. But for the exam i will go for A
Comment: The service is designed to be highly scalable, highly available, and highly durable. Amazon EFS offers the following file system types to meet your availability and durability needs ->https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html Amazon S3 achieves high availability by replicating data across multiple servers within AWS data centers->https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
Comment: But option A doesn't address the need for the application to pull the batch jobs from the new storage, also is the use of EFS needed here? In terms of it being a shared storage and whatnot..
Comment: A>>>>>
Comment: The service is designed to be highly scalable, highly available, and highly durable. Amazon EFS offers the following file system types to meet your availability and durability needs ->https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html Amazon S3 achieves high availability by replicating data across multiple servers within AWS data centers->https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
Comment: Option D
Comment: HTTP based application so ALB is required. because static IP addresses are required, we should use global accelerator: "By default, Global Accelerator provides you with static IP addresses that you associate with your accelerator."
Comment: Option D
Comment: Why D cause i think global accelerator will do a better job an cloudfront to increase availability and performance
Comment: than cloudfront*
Comment: CloudFront doesn't support assigning a static IP address to distributions
Comment: Http based app=ALB static IP= AWS global accelerator for those who choice ''A'' NLB doesn't support Http based traffic it is just used for TCP/UDP based traffic.
Comment: Something wrong in the question, here is why: Static IP addresses are required --> NLB protect against common web exploits --> WAF (But you can't use WAF directly with NLB) HTTP-based application --> Cloudfront (using CloudFront with NLB is not recommended) EC2s in multiple AWS Regions --> Route 53 latency-based
Comment: Changing my answer to B Static IP addresses are required --> We can use Global Accelerator for fixed IP and WAF on the ALB
Comment: Option A Static IP --> NLB against common web exploits --> WAF performance --> Global Accelerator is best choice in this situation.
Comment: No, option B is correct. * WAF (L7) does not work with NLB (L4) * Traffic enters via the Global Accelerator, so that's the customer-facing (static) IP - https://docs.aws.amazon.com/global-accelerator/latest/dg/about-accelerators.eip-accelerator.html
Comment: Option D
Comment: CloudFront uses multiple sets of dynamically changing IP addresses while Global Accelerator will provide you a set of static IP addresses as a fixed entry point to your applications
Comment: Option D
Comment: Correct Answer is C. Static IP addresses are required specific to the requirement.
Comment: CloudFront uses multiple sets of dynamically changing IP addresses while Global Accelerator will provide you a set of static IP addresses as a fixed entry point to your applications
Comment: Network Load Balancer (NLB): NLB operates at layer 4 and does not support AWS WAF directly https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
Comment: The company wants to improve the availability and performance of the application
Comment: Static IP addresses are required, so option B....global accelerator with ALB
Comment: B is correct
Comment: By using Amazon RDS Proxy, your applications can pool and share database connections. This pooling improves scalability by allowing multiple application instances to reuse existing connections. It also makes your applications more resilient to database failures. When a primary database instance fails, RDS Proxy automatically connects to a standby DB instance while preserving application connections. =>https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html
Comment: Option B
Comment: Option B
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/tutorial-s3-object-lambda-redact-pii.html
Comment: thanks
Comment: Use AWS Lambda functions to change the Object before it is retrieved by the caller application. Only one S3 bucket is needed, on top of which we create S3 Access Point And S3 Object Lambda Access Points Use case: 1. Redact PII for analytics or non-production environment 2. Convert across data formats ex: XML to Json 3. Resizing and watermaking images on fly using caller-specific details ex: user who requested the object
Comment: Creating a RAID 0 array allows you to achieve a higher level of performance for a file system than you can provision on a single Amazon EBS volume. Use RAID 0 when I/O performance is of the utmost importance. With RAID 0, I/O is distributed across the volumes in a stripe. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html
Comment: A is the correct choice.
Comment: A is the best choice
Comment: Option A
Comment: A. Enable termination protection for the EC2 instance. No. Termination protection is about avoid accidentally delete the instance B. Configure the EC2 instance for Multi-AZ deployment. No. Question says "cannot run on more than one instance" C. Create an Amazon CloudWatch alarm to recover the EC2 instance in case of failure. Yes. CloudWatch can be used to recover the instance: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingRecoverActions D. Launch the EC2 instance with two Amazon Elastic Block Store (Amazon EBS) volumes that use RAID configurations for storage redundancy. No. Raid could be helpful to increase resilience, but does not help with "improve the recovery time"
Comment: Option C
Comment: i think D is the answer. Cause the question asks for a resilient solution and EBS with RAID config can balance between the performance and redundancy. EBS can also help with faster launch.
Comment: But how does that "improve the recovery time for the system"?
Comment: Your solution can't resolve the problem
Comment: Option should be B .They are not asking about storage anywhere. In muti-AZ you application runs on the primary and the secondary is kept in sync.
Comment: Question about """improve the recovery time for the system""" RAID improves data resilience, but won't recover the instance if the system itself fails. it's 100% C
Comment: Pretty sure option D is NOT correct. > RAID 5 and RAID 6 are not recommended for Amazon EBS (...). > RAID 1 is also not recommended for use with Amazon EBS. https://docs.aws.amazon.com/ebs/latest/userguide/raid-config.html#raid-config-options
Comment: So what is the answer?
Comment: C: You can create an Amazon CloudWatch alarm that monitors an Amazon EC2 instance and automatically recovers the instance if it becomes impaired due to an underlying hardware failure or a problem that requires AWS involvement to repair. Terminated instances cannot be recovered. A recovered instance is identical to the original instance, including the instance ID, private IP addresses, Elastic IP addresses, and all instance metadata.
Comment: For those who choose C, the question asks that "must design a resilient solution".. C may improve recovery time but it has nothing to do with resiliency.
Comment: "resilient solution that can improve the recovery time for the system" , resiliency here means only
Comment: Option C
Comment: Can only run 1 instance. improve recovery time.
Comment: Option B. Question never ask anything about storage.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html
Comment: Amazon EKS self-managed nodes require you to manually install and configure the Kubernetes node components, such as kubelet, kube-proxy, and Docker, on your Amazon EC2 instances. You also need to manage the security group, IAM role, and subnet for your node group. Amazon ECS handles these tasks for you when you use the Amazon EC2 launch type .
Comment: but it requires minimum change in application. I believe when changing to ECS, its a huge change
Comment: Containerized.. = ECS
Comment: why not lambda?
Comment: Containerized... The solution must require minimal changes to the application.
Comment: lamda dont have containerized
Comment: Option A
Comment: Technically, expedited retrieval for files is not guaranteed within 1-5 minutes for files larger than 250 MB+. See https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects-retrieval-options.html.
Comment: S3 Standard-IA is for data that is accessed less frequently, but requires rapid access when needed. S3 Standard-IA offers the high durability, high throughput, and low latency of S3 Standard, with a low per GB storage price and per GB retrieval chargehttps://aws.amazon.com/s3/storage-classes/
Comment: A is most correct ✅
Comment: "Expedited Retrieval, you can retrieve small amounts of data (up to 250 MB per request) within 1-5 minutes." Cannot C
Comment: (A) is eliminated. Demand metric is popularly based & cannot be configured with Lifecycle policies. Ex: an old movie can have resurgent demand 20 years after it's sequel is released. (C) is eliminated. Expedited retrieval is for all but the largest archived objects (250 MB+). (D) is eliminated. Bulk retrieval takes hours. (B) is more expensive than S3 Glacier Flexible Retrieval but it's the only one that works.
Comment: AS the pattern is uncertain- Customer could not, in advance, segregate data, the pattern will be determined on the fly - and with regard of the following S3 feature: S3 Intelligent-Tiering is an additional storage class that provides flexibility for data with unknown or changing access patterns. It automates the movement of your objects between storage classes to optimize cost. C will be the most cost effective for this use case.
Comment: More insight: S3 Glacier Flexible Retrieval for the most flexible retrieval options that balance cost with access times ranging from minutes to hours. Your retrieval options permit you to access all the archives you need, when you need them, for one low storage price. This storage class comes with multiple retrieval options: - Expedited retrievals (restore in 1–5 minutes) - Standard retrievals (restore in 3–5 hours) - Bulk retrievals (restore in 5–12 hours). Bulk retrievals are available at no additional charge
Comment: Expedited 1-5min and for new files intelligent tier is a good option
Comment: All old files should be in--> Glacier Flexible Retrieval takes (1-5 minutes) to retrieve the file. New files should not stay in Standard Storage class forever --> Intelligent-Tiering
Comment: I don't think C is an option, S3 Glacier Flexible takes hour to retrieve the data. Option A is actually valid, but the way the option A describe it does not consider "demand patterns based on time" So it should be B
Comment: expedited retrieval should not be used in that way as well
Comment: There is something I like about option A. It's the only one that deals with what happens with a movie that goes from "new" to "old". With other options, new movies will be new forever.
Comment: Option B makes the most sense. Why not option C: 1. This is not an archival use case, the company runs a video streaming service, so objects are still accessed regularly. Accelerated Retrieval is designed for "occasional urgent requests for a subset of archives". 2. The 5 minute timeframe does not apply to items of 250+ MB. 3. Even if the timeframe were valid, it's not guaranteed ("typically") 4. Expedited retrieval is expensive if used frequently ($10.00 per 1,000 requests) - depending on access patterns, this may more than offset the savings in storage costs. https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects-retrieval-options.html
Comment: Option C
Comment: Expedited Retrievals (1-5 minutes) Intelligent-Tiering cost
Comment: Expedited Retrievals (1-5 minutes) - Intelligent-Tiering cost
Comment: I go with C
Comment: C -> Expedited Retrievals (1-5 minutes) - Intelligent-Tiering cost (cost effective) D -> Bulk retrievals (5-12 hours) A -> does not consider demand patterns B -> It's ok, but "C" is more good fit to access patterns
Comment: option A is most correct option B..for moving files to standard IA , it needs to stay in S3 standard for minimum 30 days. option C..expedited retrieval does not necessarily guarantee big size file retrieval in <=5 minutes. option D... is also wrong as it would take time in hours. sam
Comment: It is possible to upload directly to standard IA.
Comment: Option C
Comment: Why C and not B?
Comment: Not B because your lambda container needs the RIC and the image is already provided, presumably without the RIC (or else it would have mentioned it)
Comment: RIC: Runtime interface clients
Comment: the infrastructure must be serverless
Comment: Creating an AWS Lambda function that uses the Docker container image with an Amazon S3 mounted volume might not be suitable because Lambda functions have limitations on execution duration (15 minutes) and storage size (maximum 512 MB in the /tmp directory).
Comment: There's no indication of runtime, so that's not the reason. A is wrong because "S3 volumes" do not exist. If the question were about S3 buckets: while it is possible to mount an S3 bucket using FUSE, this is completely unsupported by AWS and definitely won't work in a container running on Lambda (you can't assign SYS_ADMIN cap and mount /dev/fuse). B is wrong because you can't use EBS volumes with Lambda. As an aside, Lambda supports up to 10 GB of ephemeral storage (configurable).
Comment: Options A and B involve AWS Lambda, which is suitable for event-driven, short-lived compute tasks, but it's NOT ideal for long-running containerized applications and managing large volumes of data.
Comment: C is right answer.
Comment: The combination of ECS with Fargate and EFS (option C) provides a serverless solution that can run Docker containers and meet the storage requirements, all while minimizing operational overhead. You don't need to manage any servers, and the storage will automatically scale as needed. This makes it the best fit for the given requirements.
Comment: Lambda would need Runtime interface clients (RIC) to host a container workload. Also Lambda storage limit: 10GB Fargate is Serverless >> C
Comment: the key word here is {" serverless + temporary file''} A: it uses S3 for storage that is not a temporary file storage system C: that was good using ECS with farget for serverless part but is uses EFS file system still it is a durable file system not temporary D: Using EBS was good to use for temporary file system but it is mounted on EC2 which is not serverless. so that we are left with ''B'' which uses [ lambda(serverless) + EBS(temporary storage)]
Comment: the key word here is {" serverless + temporary file''} A: it uses S3 for storage that is not a temporary file storage system C: that was good using ECS with farget for serverless part but is uses EFS file system still it is a durable file system not temporary D: Using EBS was good to use for temporary file system but it is mounted on EC2 which is not serverless. so that we are left with ''B'' which uses [ lambda(serverless) + EBS(temporary storage)]
Comment: The solution that best meets the requirements. This approach provides a pathway for authenticating LDAP users to AWS without requiring direct LDAP to AWS IAM Identity Center integration or SAML compatibility, offering a flexible and secure method to extend on-premises authentication mechanisms to AWS services.
Comment: Why not option A A. Enable AWS IAM Identity Center (AWS Single Sign-On) between AWS and the on-premises LDAP.
Comment: (A) is incorrect bc to use AWS IAM Identity Center (AWS Single Sign-On) with an external IdP, you need SAML.
Comment: AnswerD
Comment: D is the answer
Comment: Identity federation can be accomplished in one of three ways. (1) Use a corporate IdP (such as Microsoft Active Directory) or a custom identity broker application. Each option uses AWS STS. (2) Create an integration that uses Security Assertion Markup Language (SAML). (3) Use a web identity provider, such as Amazon Cognito.
Comment: YEA SURE FED
Comment: option D As per described here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html#id_roles_common-scenarios_federated-users-idbroker option A is wrong becouse for use SSO need to be compatible with SAML (at least this is what i understand from here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html#id_roles_common-scenarios_federated-users-saml20 )
Comment: Option D A custom identity broker application can be built to perform a similar function to an identity store that is not compatible with SAML 2.0. The broker application authenticates users, requests temporary credentials from AWS, and provides them to the user to access AWS resources.
Comment: Why not option A A. Enable AWS IAM Identity Center (AWS Single Sign-On) between AWS and the on-premises LDAP.
Comment: If your identity store is not compatible with SAML 2.0, then you can build a custom identity broker application to perform a similar function. .....option D
Comment: Recycle Bin is a data recovery feature that enables you to restore accidentally deleted Amazon EBS snapshots and EBS-backed AMIs. When using Recycle Bin, if your resources are deleted, they are retained in the Recycle Bin for a time period that you specify before being permanently deleted. You can restore a resource from the Recycle Bin at any time before its retention period expires. This solution has the least operational overhead, as you do not need to create, copy, or upload any additional resources. You can also manage tags and permissions for AMIs in the Recycle Bin. AMIs in the Recycle Bin do not incur any additional charges.Reference:
Comment: Option C https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recycle-bin-working-with-rules.html
Comment: C is correct
Comment: Option C https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recycle-bin-working-with-rules.html
Comment: Option C is correct. Recycling bin is a new feature to protect snaps and AMIs from accidental or malicious deleting. Inside the recycling bin, set a retention policy, and then your images or snapshots are protected.
Comment: https://aws.amazon.com/about-aws/whats-new/2022/02/amazon-ec2-recycle-bin-machine-images/
Comment: Option C
Comment: Option B
Comment: AnwerB SnowBall Storage will give us 80TB. To transfer data we will need 2 devices. Taking into consideration that 1 device = ~300$ we will spend 600$. Option B is most Cost effective and will allow us to end operation in lest then month.
Comment: Snowball base free from 200USD, Snowmobile base fee from 4100USD (According to AWS)
Comment: Snowmobile advised above 10 Petabytes Snowball(s) below 10 PB
Comment: Option B - Snowmobile have higher cost
Comment: Amazon S3 Transfer Acceleration must be very expensive Correct in such case : B Snowball
Comment: B is correct
Comment: Option B
Comment: Option B: 1 Snow Ball Max Allowed capacity is 80 TB. Hence, you need to order multiple snowballs to achieve the requirement.
Comment: B. Its only 150TB
Comment: I'm between B and C. Since RDS requires an additional configuration for PTR, it adds an operational overhead. So I will go with B. Aurora provides automated backup and point-in-time recovery, simplifying backup management and data protection. Continuous incremental backups are taken automatically and stored in Amazon S3, and data retention periods can be specified to meet compliance requirements. RDS provides the same but first, the users should set a retention period for these backups, allowing historical data recovery in case of accidental data loss or corruption, and point-in-time recovery (PITR) allows users to restore the database to any specific moment within the set retention period.
Comment: Answer is B. please see below article https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-pitr.html
Comment: Auroralo maigeuleisyeonhalyeomyeon MySQLboda akitegcheo byeongyeong-i deo pil-yohal su issseubnida. ganeunghamyeon choesohan-ui byeongyeong-eul yocheong 67 / 5,000 Migrating to Aurora may require more architectural changes than MySQL. Request minimal changes if possible.
Comment: AnswerB The problem with this question is that we do not have enough information. We can execute task with both AURORA or RDS DB. I will go with AURORA as it is Amazon Proprietary and is developed by AWS teams, hence we do not need to think about updates etc. as it is done by AWS teams.
Comment: B is the correct option.
Comment: B: Amazon Aurora is a fully managed relational database engine that's compatible with both MySQL and PostgreSQL
Comment: PTR, it's Aurora
Comment: It's C. Strictly speaking, there is no AWS DB call Amazon Aurora "MySQL"
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.html
Comment: C. This option aligns with the requirements by keeping the web tier in public subnets, migrating the application tier to EC2 instances in private subnets to enhance security, and using Amazon RDS for MySQL in private subnets to meet the database requirements with minimal operational overhead. option A:While migrating the web tier and application tier to EC2 instances in private subnets minimizes exposure to the internet. option B:. Migrating the database tier to Amazon Aurora MySQL introduces changes to the database engine, which might require additional testing and adjustments to the application. Additionally, Aurora MySQL does not directly support point-in-time recovery; instead, it uses continuous backups and snapshots for data recovery.
Comment: Option A works better
Comment: Option B
Comment: The correct option to provide access to the SQS queue without giving up the other company's account permissions is: C. Create an SQS access policy that provides the other company access to the SQS queue. By creating an SQS access policy, you can define specific permissions for the other company to access the SQS queue without requiring them to modify their own account permissions. This allows for fine-grained control over access to the queue while maintaining security and isolation between accounts. Options A, B, and D are not appropriate for granting access to the SQS queue in this scenario.
Comment: AnswerC Creating Access policy in SQS which will allow other company to acess SQS queue seems to be the only solution which is RIGHT here
Comment: Amazon SQS policy system lets you grant permission to other Amazon Accounts. https://docs.amazonaws.cn/en_us/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-using-identity-based-policies.html
Comment: SQS Access Policy for secure, fine-grained Cross-account access
Comment: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-overview-of-managing-access.html
Comment: option A: Instance profiles are used to grant permissions to EC2 instances, not for granting access to other AWS services like SQS queues. Option B.:AM policies are applied to IAM users, groups, or roles within the same AWS account. They are not directly applicable to granting access to resources in other AWS accounts. option C:SQS access policies allow you to grant cross-account access to SQS resources. You can specify the necessary permissions in the policy and attach it directly to the SQS queue. This way, you can give the other company's AWS account the necessary permissions to poll the queue without compromising their account permissions. option D. Amazon SNS access policies are used to manage access to SNS topics, not SQS queues
Comment: Option C
Comment: Option B
Comment: Option D
Comment: SSM is always the recommended way of connection for EC2 "using ssh". It's the most cost effective and the most secure way of doing the job.
Comment: AWS Systems Manager Session Manager is a service that enables you to securely connect to your EC2 instances without using SSH keys or bastion hosts. You can use Session Manager to access your instances through the AWS Management Console, the AWS CLI, or the AWS SDKs. Session Manager uses IAM policies and roles to control who can access which instances. By attaching the AmazonSSMManagedlnstanceCore IAM policy to an IAM role that is associated with the EC2 instances, you grant the Session Manager service the necessary permissions to perform actions on your instances. You also need to attach another IAM policy to the developers' IAM users or roles that allows them to start sessions to the instances.
Comment: Why not C?
Comment: it doesn`t meet requirements MOST cost-effectively
Comment: Option D
Comment: Option D
Comment: Option C
Comment: B. Deploying an AWS Storage Gateway file gateway with an Amazon S3 bucket as the target storage would require the entire dataset to be stored in Amazon S3, which might not be cost-effective considering that only a subset of the data needs to be accessed regularly. Additionally, accessing data directly from S3 might introduce latency. so correct option is C bcz AWS Storage Gateway volume gateway with cached volumes allows the company to keep frequently accessed data locally on-premises while storing the entire dataset in Amazon S3. This solution provides immediate access to the subset of data with minimal lag, as frequently accessed data is cached locally. It also reduces ongoing capital expenses as it leverages Amazon S3 storage, which is cost-effective.
Comment: Both B and C store the entire data set in Amazon S3 and the AWS Storage Gateway file gateway also supports local caching. I do not know if it is B or C for me.
Comment: AnswerC Deploying an AWS Storage Gateway volume gateway with cached volumes will allow to store all data in AWS but the most frequently accessed data will be stored/cached localy (on-premises) = low latency for most used data while all data will be stored in the cloud. https://docs.aws.amazon.com/storagegateway/latest/vgw/StorageGatewayConcepts.html#storage-gateway-cached-concepts
Comment: A storage guy here.. the question is not clear enough to give a definitive answer between B and C, as both can do the job. An "on-prem storage array" can be any of the three: - File array (serving any file protocol, e.g. NFS/SMB) -> requiring a file gateway (supports caching of the most recently used data) - Block array (iSCSI/Fibre Channel) -> requiring a volume gateway (supports cached volumes most recently used data) - Combo (providing both File and Block protocols) Something is clearly missing in the question in order to give a definitive answer between B and C.
Comment: storage arrays = Volume Gateway
Comment: storage array, also known as a disk array so AWS Storage Gateway volume. its a trap
Comment: C is correct. Using AWS Storage Gateway volume gateway with cached volumes provide local access to the file.
Comment: require a subset of the entire dataset => cached volumes
Comment: The company's researchers regularly require a subset of the entire dataset to be immediately available with minimal laghttps://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html
Comment: Option A
Comment: AnswerA Point-in-time recovery helps protect your DynamoDB tables from accidental write or delete operations. With point-in-time recovery, you don't have to worry about creating, maintaining, or scheduling on-demand backups. For example, suppose that a test script writes accidentally to a production DynamoDB table. With point-in-time recovery, you can restore that table to any point in time during the last 35 days. After you enable point-in-time recovery, you can restore to any point in time from five minutes before the current time until 35 days ago. DynamoDB maintains incremental backups of your table. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html
Comment: A is correct. One of the highlight features of DynamoDB.
Comment: option A
Comment: A looks correct
Comment: Option A
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html
Comment: AnswerB
Comment: The problem with C is how it sends the data to S3, if it was Firehose it would make sense. I waka for B.
Comment: B is correct. The most cost effective option.
Comment: option B
Comment: option b bcz option c is WS AppSync is not the most appropriate solution for file processing. option d While Amazon Simple Notification Service (SNS) can be used to trigger actions based on S3 events, it's not directly involved in processing files .option c :Kinesis is typically used for real-time data streaming and analytics, which may not be needed for simple file processing tasks such as extracting metadata.
Comment: Option D
Comment: B seems to be make most sense to me.
Comment: Option D
Comment: Option C
Comment: "An Amazon EC2 Dedicated Host is a physical server fully dedicated for your use, so you can help address corporate compliance requirements." https://aws.amazon.com/ec2/dedicated-hosts/ That already eliminates "A" and "D". No need to pay extra since there is no requirement for eligible software licences. B is INCORRECT = no need to use reserved instances for non-prod, since they will only be active during business hours during weekdays.
Comment: AnswerC We need to use somekind of savings plans for production and disable Development servers when we are not using them. Only Option C has both.
Comment: Definitely C.
Comment: Option C
Comment: It's C
Comment: Option C
Comment: Option C
Comment: Answer C
Comment: C is correct. As we need to capture the change during the migration.
Comment: I don't want confuse other...
Comment: AWS Lambda can run Docker containers, but it is more suited for short-duration, event-driven functions rather than long-running services. While you can use Lambda to run container images, it is typically used for microservices or functions rather than managing scalable containerized applications in the same way that ECS or EKS does.
Comment: - Container = ECS or EKS - "managed service to host the application" = Fargate - "not result in additional operational overhead or infrastructure to manage" = ECS for the win. The main difference between ECS and EKS = simplicity vs flexibility. https://aws.amazon.com/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/
Comment: now, if instead of asking the "best" (combination) solution you want TWO SOLUTIONS, then I see value in A-B.
Comment: For sure
Comment: Why so many trolls recently...
Comment: glowies out reeeeeeeeeeeeeeee
Comment: The question is asking for two alternatives to run Docker containers in a serverless service with minimal effort. Option C will require a lot of effort to configure the Lambda and the API Gateway to run the Container correctly. Instead, just use EKS o ECS with Fargate to execute the container image
Comment: It should be AB
Comment: It should be AB, Container :ECS , EKS
Comment: No, I decided to change my option since this question is asking "Docker"&"AWS" it is not asking local Kubernet, so AC should be the right answer.
Comment: AB are using AWS Fargate which IS considered a managed service, option C does not run containers, , DE you have to manage your own EC2 instances thus not consider managed
Comment: Everyone is picking AB too..
Comment: Option AB
Comment: Are people picking A&B as alternate solutions? Is the question asking for alternates?? Am I missing something? Somebody explain please I'm super confused.
Comment: I believe so. Based on other questions, they would have asked "which combination"
Comment: The question states itself. Which Solutions....?
Comment: Option AB
Comment: Option AB
Comment: Option D
Comment: The most cost-effective solution is: D. Configure an Auto Scaling group to scale out as traffic increases. Create a launch template to start new instances from a preconfigured Amazon Machine Image (AMI).
Comment: En la respuesta C : Al usar servicios como Amazon CloudFront y Amazon ElastiCache para almacenar en caché el contenido dinámico, reduciendo la carga en las instancias de Amazon EC2 y mejorando la velocidad de entrega del contenido a los usuarios finales. Esto resulta en una solución más rentable y eficiente en comparación con la respuesta D : simplemente escalar instancias de EC2 sin considerar medidas adicionales para optimizar el rendimiento y reducir los costos . Por lo que la opción correcta es la C .
Comment: Cloudfront coulld be a good idea, but it seems to be a simple scaling scenario.. IMO: D
Comment: Don't we need a launch template? How can it just launch from AMI image
Comment: Answer is D .C is not cost effective to use elasticache .Not sure if you can have ASG as the origin.
Comment: Sorry D
Comment: Option C
Comment: Option D bring a most cost effective
Comment: C more suitable
Comment: It's D
Comment: Option B
Comment: The others sound 'silly'... to say the least
Comment: B looks correct
Comment: Option B https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html
Comment: option b
Comment: Option B
Comment: VPC Lattice is a completely new way to simplify API communication between services or microservices in one or more AWS accounts.
Comment: Amazon VPC Lattice is a new capability of Amazon Virtual Private Cloud (Amazon VPC) designed to simplify networking for service-to-service communication. link: https://www.bing.com/search?q=what+VPC+Lattice+service+used+for+microservices&cvid=d706d95737274f388660cbda9b7b2c4e&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIICAEQ6QcY_FXSAQkyMTY1N2owajSoAgCwAgE&FORM=ANAB01&PC=U531
Comment: Did you complete the exam recently? Was examtopics useful?
Comment: Please keep in mind this is for helpful answers to THIS specific question. Please don't abuse it as a random info pitch for yourself. This is distracting and wasting others' time. Please respect other people's time.
Comment: IT's B. Google VPC Lattice service network
Comment: Option B
Comment: Option C is better as we need replication and snapshots
Comment: C is correct as only Redis support snapshot feature :https://aws.amazon.com/elasticache/redis-vs-memcached/
Comment: C is correct
Comment: Thinking the capabilities with "snapshots, replication, and sub-millisecond response times" is for the Database or selected solution(ElastiCache).
Comment: C is correct
Comment: Réponse C
Comment: :https://aws.amazon.com/elasticache/redis-vs-memcached/
Comment: Option D
Comment: Changing to options AC
Comment: AnswerAC Option A will allow to run/lunch AMIs Option C will allow to decript AMIs which is necessery to run AMI.
Comment: CD - Solution C: Update the Key Policy Why: The AMIs are created using KMS-encrypted snapshots, so the KMS keys must allow the development team's accounts to use these keys for decrypting the snapshots. How: Update the key policy of the KMS key to include permissions for the development OU or specific accounts within that OU. This will enable those accounts to use the KMS key for decrypting the snapshots associated with the AMIs. Solution D: Add the Development Team's Account ARN to the Launch Permission List Why: To share the AMIs with the development accounts, you need to grant launch permissions to those accounts. This allows the specified accounts to use the shared AMIs to launch instances. How: Add the ARNs of the development team's accounts to the launch permission list of the AMIs. This can be done using the modify-image-attribute command in the AWS CLI, specifying the account IDs that should have launch permissions.
Comment: A : give users the right to launch C : give users the right to decrypt
Comment: c=>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-amis-with-organizations-and-OUs.html#allow-org-ou-to-use-key A-->https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-amis-with-organizations-and-OUs.html#share-amis-org-ou
Comment: Option CD
Comment: B because too many offices that are geographically separated. "data analytics company has 80 offices that are distributed globally."
Comment: Nice spot...completely missed that part !!
Comment: AWS Snowmobile: ideal for migrating big datasets containing 10PB or more and stored in one location. Snowmobile can help you migrate all of these large datasets at once, but the process requires a high-speed backbone with hundreds of Gb/s of spare throughput. AWS Snowball: ideal for datasets storing less than 10PB or datasets distributed across multiple locations. You can use Snowball to migrate data incrementally—this is a good alternative if you do not have enough bandwidth on the network backbone. https://bluexp.netapp.com/blog/aws-cvo-blg-aws-snowball-vs-snowmobile-data-migration-options-comparedwork backbone.
Comment: 10 Snowball price (100TB x 10) still cheaper then 1 Snowmobile price ($4,100 plus additional cost for data transfer)
Comment: Why not D? Why not AWS storage gateway? With 1Gbps, they can transfer 1.25 GBPS which translates to 2.8 PB in 4 weeks. They need just 1 PB to be transferred
Comment: As of March 2024 AWS has stopped offering snowmobile as a service .So B is the right answer.Hopefully they don't ask this question :)
Comment: Too large for snowball devices.
Comment: Option C, An AWS Snowmobile has a maximum storage capacity of 100 petabytes (PB). This is equivalent to the capacity of 1,250 Snowball Edge devices
Comment: but there are many offices geographically distributed, so snowmobile for each one of them adds up to a lot of cost as compared to option B).
Comment: Snowmobile advised over 10PB! Definitely snowball
Comment: option B
Comment: Option C looks good, as option B would lead to usage of too many snowball devices.
Comment: Create an EFS access point for each application. Use Portable Operating System Interface (POSIX) file permissions to allow read-only access to files in the root directory. Explanation: By creating an EFS access point for each application and configuring POSIX file permissions to allow read-only access, you can enforce the desired access control. This approach restricts write and delete actions on the dataset while allowing read access, aligning with the company's requirements.
Comment: Resource policies are included in " IAM to control": "Using IAM to control file system data access NFS clients can identify themselves using an IAM role when connecting to an EFS file system. When a client connects to a file system, Amazon EFS evaluates the file system's IAM resource policy, which is called a file system policy, along with any identity-based IAM policies to determine the appropriate file system access permissions to grant." https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html
Comment: Please note that the question is asking "The company wants to use IAM access control to prevent the applications from being able to modify or delete the dataset."
Comment: B correct best solution best well architected C wrong because identity policies are typically associated with users or roles, not directly with the EFS file system D wrong because POSIX file permissions at the root directory level may not be sufficient to prevent modifications to other directories or files A is so far away
Comment: - Identity-based policies are attached to an IAM user, group, or role. - Resource-based policies are attached to a resource. - elasticfilesystem:ClientWrite: Provides write permissions on a file system. EFS is a RESOURCE, so that excludes "C" (we need a resource policy). https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html
Comment: There is no such thing as an "identity policy" for EFS.
Comment: 2 ways to prevent writing to the file system: 1. The mount option in the /etc/fstab file is set to read-only access. > A 2. IAM policy indicates read-only access, or root access disabled. > B The question clearly states they are looking to use IAM access control
Comment: prevent the applications from being able to modify or delete the dataset.-- This means a role would be used. So answer is B
Comment: IAM policies are used to control access to AWS resources, including Amazon EFS. By default, IAM policies control access to the EFS API actions, such as elasticfilesystem:ClientWrite, which allows clients to write to the file system. However, POSIX file permissions control access to files within the file system itself, which is independent of IAM policies. While using POSIX file permissions can restrict access to the files within the file system, it doesn't prevent a user or application with the appropriate IAM permissions from modifying or deleting those files directly through the EFS API.
Comment: B) IAM needs to be used, so A) & D) are out. So b/w B) and C), Resource policies are meant for specific aws service or resource while Identity policies are attached to an identity (user, group or role). C) attached identity policy to EFS, dont know how and why. Hence, B).
Comment: company wants to use IAM access control to prevent https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html
Comment: option D
Comment: "The company wasn't to use IAM access control". Yes, it would deny writing action to everything .. but it's still the only one that uses IAM.
Comment: "Using IAM to control file system data access NFS clients can identify themselves using an IAM role when connecting to an EFS file system. When a client connects to a file system, Amazon EFS evaluates the file system's IAM resource policy, which is called a file system policy, along with any identity-based IAM policies to determine the appropriate file system access permissions to grant." https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html
Comment: What we need to change is the " IAM resource policy".
Comment: Option B
Comment: When you have somebody from another account who needs a resource in your account - create a role to access to this account - allow the remote account to asume the role.
Comment: Option A looks ok
Comment: AnswerA I would go with option A
Comment: Question #222
Comment: Nothing with cost explorer in it, and I don't want to be Captain Obvious but we need to set the budget alerts through AWS Budgets, so A
Comment: AnswerA https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html
Comment: Option A
Comment: Option B
Comment: none sense why IGW on top of NATGW.
Comment: https://docs.aws.amazon.com/network-firewall/latest/developerguide/arch-igw-ngw.html Confusing, I agree. But it seems to be recommended in some cases.
Comment: AnswerB Server and LB in Private will hide WEB application from the word. NAT will allow for server's access to the internet in case of need
Comment: B is well structured
Comment: To my opinion, with only having inbound of the companys CIDR block, it will not include access for the patches available online. i would go for D
Comment: Incorrect: B says inbound, D says outbound. Outbound for ALB are the EC2 Instances.
Comment: Option B
Comment: Option D
Comment: AnswerD Amazon Quantum Ledger Database (Amazon QLDB) is a fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log owned by a central trusted authority. https://docs.aws.amazon.com/qldb/latest/developerguide/what-is.html
Comment: Amazon Quantum Ledger Database (Amazon QLDB) is a fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log.
Comment: immutable, cryptographically verifiable ==> Amazon QLDB
Comment: Amazon QLDB • QLDB stands for ”Quantum Ledger Database” • A ledger is a book recording financial transactions • Fully Managed, Serverless, High available, Replication across 3 AZ • Used to review history of all the changes made to your application data over time • Immutable system: no entry can be removed or modified, cryptographically verifiable
Comment: https://aws.amazon.com/qldb/ Amazon Quantum Ledger Database (Amazon QLDB) is a fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log.
Comment: D is correct
Comment: data preparation = Glue DataBrew https://docs.aws.amazon.com/databrew/latest/dg/what-is.html state handling = DataBrew with Step Functions https://docs.aws.amazon.com/step-functions/latest/dg/connect-databrew.html
Comment: Option C
Comment: AnswerC With Step Functions' built-in controls, you can examine the state of each step in your workflow to make sure that your application runs in order and as expected. https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html AWS Glue is a serverless data integration service that makes it easy for analytics users to discover, prepare, move, and integrate data from multiple sources. https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html
Comment: c looks correct
Comment: Standard queues provide at-least-once delivery, which means that each message is delivered at least once. FIFO queues provide exactly-once processing , which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue. OPTION C
Comment: AnswerC SQS FIFO was created for such tasks Unlike standard queues, FIFO queues don't introduce duplicate messages. FIFO queues help you avoid sending duplicates to a queue. If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues-exactly-once-processing.html
Comment: C over D, because https://docs.aws.amazon.com/lambda/latest/dg/with-ddb.html Processing dynamo streams with lambda can cause duplication. SQS FIFO can be configured for High Throughput to exceed the 3000/s (batched) limit https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/high-throughput-fifo.html I previously worked with payments and would argue that either option doesn't fully solve duplications. Events might be sent multiple times from source, you definitely want to perform de-duplication and have some sort of idempotent processing for them, instead of just blindly processing each thing you're given.
Comment: c is correct
Comment: Option C: FIFO queues Exactly-Once Processing – A message is delivered once and remains available until a consumer processes and deletes it. Duplicates aren't introduced into the queue. First-In-First-Out Delivery – The order in which messages are sent and received is strictly preserved.
Comment: Option C Fifo
Comment: SQS can have duplicate messages in case of problems with the timeout window.
Comment: "The application does not process duplicate payments" is the key point, which leads us directly to SQS FIFO
Comment: Option D DynamoDB Streams helps ensure the following: Each stream record appears exactly once in the stream. For each item that is modified in a DynamoDB table, the stream records appear in the same sequence as the actual modifications to the item. DynamoDB Streams writes stream records in near-real time so that you can build applications that consume these streams and take action based on the contents.
Comment: Option D...If you need to handle millions of transactions each day, you might need to consider other approach instead of SQS FIFO. And amongst the given options, we have DynmamoDB that maintains order in the streams.
Comment: I'm not sure if the answer is DynamoDB as well, but answering your question, SQS Fifo can handle 300 messages/second without batching, 3,000 messages/second with batching. Assuming we're using the 300/sec option, with 86,400 seconds in a day, that gives you 25,920,000 messages, so in short, yes SQS can handle millions of requests each day. Not to mention DynamoDB doesn't provide the exactly-once processing the SQS offer and clearly requested in the question. That's just my train of thought, I'm happy to be corrected.
Comment: Dynamodb streams with partition key can be used to implement exactly once processing. There are many options with dynamodb to check for already processed item, and can be filtered out so that they are processed only once.
Comment: This calculation limits the number of transactions to 25 million a day. What if there are transactions exceeding this limit? As question say .... millions of transactions a day; that could be 70,80 or 90 millions also. In that case how SQS FIFO would perform? Happy to be corrected with more convincing facts
Comment: Option c
Comment: Option B
Comment: AnswerB AWS Migration Hub delivers a guided end-to-end migration and modernization journey through discovery, assessment, planning, and execution. https://aws.amazon.com/migration-hub/ AWS Application Discovery Service helps you plan your migration to the AWS cloud by collecting usage and configuration data about your on-premises servers and databases. Application Discovery Service is integrated with AWS Migration Hub and AWS Database Migration Service Fleet Advisor. https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html
Comment: Still the planning stage, C and D is out.
Comment: Option D
Comment: Sorry B
Comment: B is correct
Comment: AWS Application Discovery Service helps you plan your migration to the AWS cloud by collecting usage and configuration data about your on-premises servers and databases. https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html
Comment: Option B
Comment: https://docs.aws.amazon.com/controltower/latest/userguide/security-hub-controls.html
Comment: Option D
Comment: A is correct
Comment: Option A
Comment: Option A
Comment: S3 + SQL = Athena
Comment: Apache Parquet => Glue Crawler
Comment: c is correct
Comment: Option C
Comment: Option C
Comment: Option D... This is preventive control of Control Tower where we use SCP to disallow actions that lead to policy violation.
Comment: proactive controls pls see links for both * in inline policy: https://docs.aws.amazon.com/controltower/latest/userguide/iam-rules.html#ct-iam-pr-1-description and for ec2 public IP: https://docs.aws.amazon.com/controltower/latest/userguide/ec2-rules.html#ct-ec2-pr-9-description
Comment: Prevent AWS CloudFormation from deploying IAM resources and EC2 instances based on specific use cases = Control Tower Proactive controls. "Proactive controls are security controls that are designed to prevent the creation of noncompliant resources. For example (...), through AWS CloudFormation, the proactive control can prevent the creation of update of any S3 bucket that has public access enabled." https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/proactive-controls.html
Comment: this is A
Comment: Is D, the best way to prevent this actions, is deploying SCPs
Comment: It is D. You want to prevent the events from happening. Proactive controls check whether resources are compliant with your company policies and objectives, before the resources are provisioned in your accounts. Detective controls detect specific events when they occur and log the action in CloudTrail. Preventive controls prevent actions from occurring. Preventive controls are implemented with SCPs. Detective controls are implemented with AWS Config rules. Proactive controls are implemented with AWS CloudFormation hooks. https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work
Comment: as stated by you A is correct, Proactive controls are implemented as cloudformation hooks and the resource will not be deployed if not compliants. It is exactly what is asked in question. Using an SCP it is actually a valid solution, but it need to be associated to a specific resource that is not specified. If you associated to root account nobody can deploy a public ip ec2, not only cloudformation
Comment: Proactive controls are implemented using AWS CloudFormation hooks within AWS Control Tower. They operate before resources are deployed to determine compliance with activated controls. SCPs are part of AWS Organizations and are used to manage permissions. vs Define specific purposes for implementing controls.https://docs.aws.amazon.com/controltower/latest/userguide/proactive-controls.html
Comment: SCPs focus on managing permissions at the OU level, while proactive controls in AWS Control Tower help prevent non-compliance during resource provisioning.
Comment: A would provide a proactive solution, also I'm not sure if SCP are made for granular details like creation of EC2 instances with public IP addresses or IAM resources with certain inline policies.
Comment: Option D
Comment: Option BE
Comment: AnswerBE, AutoScaling to increase amount of servers per need, Load Balancer to palance traffic equaly to all available servers
Comment: Only BE makes sense, even though it might require modification of the application
Comment: Why isn't C the answer?
Comment: nat gateway is for accessing internet-facing from private subnets, not the other way around
Comment: be are correct
Comment: Option B & E
Comment: Option BE
Comment: Option D
Comment: "To configure encryption for your environment variables Enable console encryption helpers to use client-side encryption to protect your data in transit. Under Encryption in transit, choose Enable helpers for encryption in transit. For each environment variable that you want to enable console encryption helpers for, choose Encrypt next to the environment variable. Under AWS KMS key to encrypt in transit, choose a customer managed key that you created at the beginning of this procedure."
Comment: I don't understand why we should use a complex way of encrypting variables instead of using Parameter Store... but in this case the best option is D
Comment: https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html#configuration-envvars-encryption
Comment: User pools is for Authentication and user management
Comment: User pools are for authentication. Your app users can sign in through the user pool, Identity pools are for authorization, give them access to other AWS services.
Comment: user pool vs identity pool: https://repost.aws/knowledge-center/cognito-user-pools-identity-pools
Comment: B offers more operational efficiency imo
Comment: Answer is A
Comment: Option A
Comment: Option C https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-and-remediate-scheduled-deletion-of-aws-kms-keys.html
Comment: option c bcz Option C emerges as the clear winner due to its: Direct event monitoring for the DeleteKey operation Pre-built automation using Systems Manager Automation runbooks Efficient notification via Amazon SNS Minimal code development and operational overhead Reduced risk of accidental deletion with faster response times
Comment: "Deletion of an AWS KMS key is scheduled. The scheduled-deletion event is evaluated by an EventBridge rule. The EventBridge rule engages the Amazon SNS topic. The EventBridge rule initiates the Systems Manager automation and runbooks. The runbooks cancel the deletion." https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-and-remediate-scheduled-deletion-of-aws-kms-keys.html
Comment: I agree with andy_09
Comment: Cloud trail helps to keep all invoked API calls in the AWS account which can trail back to the delete call made by a user CloudWatch triggers an alarm when deletion is attempted. SNS sends a notification to the administration about the attempt made. All these met the requirement of the question.
Comment: My educated guess was C. Now, reading the comments, from Hajrá313 and knben I feel confident as well :)
Comment: It's D https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html#cloudwatch-alarm-prerequisites
Comment: C as it " cancel the deletion of the KMS key"
Comment: I would go with C A -> Config is for compliance B -> No lambda is required, too much complexity C -> It achieves the goal, since KMS keys are not immediately deleted, which gives time to automation to cancel the action D -> Cloudtrail is for auditing
Comment: I agree with hajra313
Comment: Option B
Comment: not sure because it says that the program producues several reports , and each takes less than 10 min. i am voting for option A
Comment: Lambda takes duration--> 15 minutes
Comment: each lambda triggering produces a report in less than 10 mins.
Comment: B is correct
Comment: "The program takes less than 10 minutes to produce each report. The company rarely uses the program to generate reports outside of the last week of each month The company wants to generate reports in the least amount of time when the reports are requested." I go for B because of this
Comment: AnswerC Option A and D are saying abount Running the EC2 instances countinously during the last week of each month which is not necessery from my understanding and will be not so cheap. Option B - 10min per report and we have couple of reports. So it looks like program is running for at least 20 min so in theory Lambda is not useful here Option C - ECS is allowing us to run Fargate which will allow to run program for more then 15 min, hence all reports which program is preparing should be created. I'm not sure but I think ECS API is allowing to run task on demand/request.
Comment: It's "15 minutes per execution", which is enough to produce a report and be ready for another invocation.
Comment: B is corre ct
Comment: B..maybe?
Comment: Options BD
Comment: BD looks right
Comment: Elastic Fabric Adapter (EFA) • Improved ENA for HPC, only works for Linux • Great for inter-node communications, tightly coupled workloads • Leverages Message Passing Interface (MPI) standard • Bypasses the underlying Linux OS to provide low-latency, reliable transport
Comment: Option B
Comment: Rekognition: for image and video analysis Comprehend: natural language processing model for uncovering insights and connections in text Sagemaker Autopilot: feature set that simplifies and accelerates and automates the various stages of the machine learning workflow
Comment: B is correct
Comment: B. Add multiple MFA devices for the root user account to handle the disaster scenario. By adding multiple MFA devices for the root user account, the company ensures that it can still access the account even if one MFA device is lost. This approach provides a backup for authentication, addressing the concern of losing access to the root user account if the MFA device is lost.
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
Comment: AnswerB Because a root user can perform privileged actions, it's crucial to add MFA for the root user as a second authentication factor in addition to the email address and password as sign-in credentials. We strongly recommend enabling multiple MFA for your root user credentials to provide additional flexibility and resiliency in your security strategy. You can register up to eight MFA devices of any combination of the currently supported MFA types with your AWS account root user. https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html#ru-bp-mfa
Comment: b looks correct
Comment: I'd go for B
Comment: Option B
Comment: SNS is designed for precisely this kind of use case. It allows you to publish messages to a topic, which can then be delivered to multiple subscribers. Partners can subscribe to the SNS topic using an HTTP endpoint as the protocol, which meets the requirement to notify partners via an HTTP endpoint. This approach is highly scalable and requires the least implementation effort because it leverages managed services without the need for custom logic to manage subscriptions or deliver notifications.
Comment: Option A involves creating an Amazon Timestream database to store affiliated partners and implementing an AWS Lambda function to read the list and send user IDs to each partner. While this approach can work, it involves more implementation effort than the Amazon SNS solution. It requires setting up and managing a database, as well as configuring the Lambda function to send notifications to partners. The Amazon SNS solution provides a simpler and more scalable approach for rapidly adding partners and notifying them when users receive points. so answer is B
Comment: AnswerB Sending Notification to multiple subscribers = SNS Amazon Simple Notification Service (Amazon SNS) is a managed service that provides message delivery from publishers to subscribers (also known as producers and consumers). Publishers communicate asynchronously with subscribers by sending messages to a topic, which is a logical access point and communication channel. Clients can subscribe to the SNS topic and receive published messages using a supported endpoint type, such as Amazon Data Firehose, Amazon SQS, AWS Lambda, HTTP, email, mobile push notifications, and mobile text messages (SMS). https://docs.aws.amazon.com/sns/latest/dg/welcome.html
Comment: This is a perfect SNS use case
Comment: The answer is B, create an SNS topic one subscriptions you can make is HTTP, This completely addresses the question objective.
Comment: Option A
Comment: AnswerA Amazon Comprehend uses natural language processing (NLP) to extract insights about the content of documents. It develops insights by recognizing the entities, key phrases, language, sentiments, and other common elements in a document. Use Amazon Comprehend to create new products based on understanding the structure of documents. For example, using Amazon Comprehend you can search social networking feeds for mentions of products or scan an entire document repository for key phrases. https://docs.aws.amazon.com/comprehend/latest/dg/what-is.html
Comment: A seems right B. Forecast is time-series C. Using Polly to create audio recordings just to make your employees listen to them seems inefficient to say the least D. Question asks for no ML. SageMaker = ML
Comment: A correct
Comment: A is correct
Comment: shouldn't it be A?
Comment: B -> VPC peering allows the Lambda access secondary account securely and efficiently A -> redundancy C -> additional complexity D -> sharing code libraries
Comment: AnswerB You can configure a function to mount an Amazon EFS file system in another AWS account. Before you mount the file system, you must ensure the following: VPC peering must be configured, and appropriate routes must be added to the route tables in each VPC. . . . https://docs.aws.amazon.com/lambda/latest/dg/configuration-filesystem-cross-account.html
Comment: https://docs.aws.amazon.com/lambda/latest/dg/configuration-filesystem.html#configuration-filesystem-cross-account
Comment: https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html
Comment: Shouldn't it be B?
Comment: I thinks AWS DataSync less costly
Comment: setting up a peering connection is free. same for data transfer in the same AZ. data sync at the end of the day cost $$$ to move data.
Comment: When you will SyncData you need to have secondary storage for which you need to pay so it is not cheap solution.
Comment: You get to do it, keep moving...
Comment: AnswerD Hence we need to encrypt data not only during the rest but during the transfer as well, we need execute client-side encyprion. SSE will only secure data during rest hence we can eliminate A,B and C. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html
Comment: Given the requirement to manage encryption keys outside the AWS Cloud, option D is the most suitable solution, despite not directly utilizing AWS's native encryption services like SSE with AWS KMS. Instead, it leverages external encryption mechanisms controlled by the company.
Comment: A Key is safe but came from the customer
Comment: A, B and C need to have the key stored in AWS cloud. D is correct.
Comment: Client-side encryption – You encrypt your data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, encryption keys, and related tools.https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html
Comment: For me it's D, it's the only one that provides encryption also in transit
Comment: A looks correct
Comment: AnswerD I would go with Lambda function to do basic validation it should not take more then 15min hence Lambda is perfect for that job. Then we have information that backend processing application is long running and we need to make compute and memory adjustment, and everythink need to be automatic as company do not want to manage infrastucture. In that situation Fargate with ECS will be ideal as it can run background application for every paymant separetly we need only adjust amunt of resources in use. More payments more application running, mmore resources in use and oposite,
Comment: Lot of grip in this question, but to keep it short: No infra: B, C Out. EKS Anywhere: Onprem + AWS: Not needed. ECS Fargate: Serverless, Least Ops Overhead, SQS fine for the queue, Lambda good for basic validation.
Comment: We want to have least overhead and no infrastructure (aka no server). So no infrastructure == not C least overhead == ECS better than EKS == not B and not A Fargate is serverless so D is still valid. So the answer is D.
Comment: D is correct
Comment: shouldn't it be D?
Comment: Data Warehouse => redshift Use AWS Services whereever possible => Redshift serverless
Comment: Neither A, nor B explicitly say "EMR serverless" which is a new AWS offering, so I exclude these two. MPP goes hand in hand with Redshift, so D is also incorrect. This leaves C the only possible serverless option here.
Comment: A Amazon EMR Serverless is a deployment option for Amazon EMR that provides a serverless runtime environment. This simplifies the operation of analytics applications that use the latest open-source frameworks, such as Apache Spark and Apache Hive. With EMR Serverless, you don't have to configure, optimize, secure, or operate clusters to run applications with these frameworks. EMR Serverless helps you avoid over- or under-provisioning resources for your data processing jobs. EMR Serverless automatically determines the resources that the application needs, gets these resources to process your jobs, and releases the resources when the jobs finish. For use cases where applications need a response within seconds, such as interactive data analysis, you can pre-initialize the resources that the application needs when you create the application.
Comment: Data warehouse ==> Redshift Without additional informations both EMR and Glue Jobs can work. Since the question asks to use serverless as much as possible, Redshift Serverless is a better solution. C
Comment: Option C
Comment: EMR works with big data transfer
Comment: MPP --> use Redshift so eliminate B,D As it required Serverless services --> Glue
Comment: A have no serverless C is the answer
Comment: C is correct
Comment: should be C
Comment: Outpost is a service where AWS has physical servers in your datacenter. C
Comment: Data must remain locally in the company's data center => AWS outpost
Comment: EKS on SnowBALL could be an option. EKS on SnowMOBILE isn't as it's used for data transfer mostly.
Comment: AnswerC AWS Outpost = Bring AWS cloud to your DataCentre, which we need in described scenario
Comment: C is correct
Comment: C looks correct
Comment: This solution meets the requirements most cost-effectively because it enables the company to migrate its on-premises NFS data store to AWS without changing the existing applications or workflows. AWS Storage Gateway is a hybrid cloud storage service that provides seamless and secure integration between on-premises and AWS storage. Amazon S3 File Gateway is a type of AWS Storage Gateway that provides a file interface to Amazon S3, with local caching for low-latency access. By setting up an Amazon S3 File Gateway, the company can store and retrieve files as objects in Amazon S3 using standard file protocols such as NFS.
Comment: S3 File Gateway => Best for NFS-like file storage workloads
Comment: Answer: C
Comment: AnswerD Taking into consideration that we are talking about social media company probably storing a lot of quite small files i would say it cannot be Option A or B. For example Amazon S3 File Gateway pricing Storage Pricing Storage Pricing Stored and billed as Amazon S3 objects. Request Pricing Data written to AWS storage by your gateway $0.01 per GB† File storage in S3 Billed as Amazon S3 requests. It can be quite expensive, especially when we will be working on small files. I would go with EFS with OneZone-IA (option D) which should be less expensive taking into consideration that we are paying only for Storage and Data Transfer (per GB). But to be honest we need more information to device which solution will be better.
Comment: It say migrating data into cloud, EFS does not satisfy that. You're right, It needs more information to make your choice to be a better answer.
Comment: yeah B
Comment: I think B too
Comment: B looks correct
Comment: eserved concurrency — It guarantees the maximum number of concurrent instances for the function which can be invoked. When a function has being with a reserved concurrency configuration then no other lambda function within the same AWS account and region can use that concurrency. There is no charge for configuring reserved concurrency for a function. Provisioned concurrency — This concurrency initializes a requested number of execution environments so that they are prepared to respond immediately to your function's invocations. Note that configuring provisioned concurrency incurs charges to your AWS account.
Comment: Also Lambda provisioned concurrency incure additionnal Account charges (https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html), it's the best option because it is stated: - The company wants to reduce the compute costs and to maintain service latency for its customers. So maintaining service latency while reducing compute cost is requested. That being said, Lambda optimization is not a trivial task, that's why one should rely on AWS Compute Optimizer recommendations to analyze usage and find the best fit. Please read following for more insights: https://aws.amazon.com/blogs/compute/optimizing-aws-lambda-cost-and-performance-using-aws-compute-optimizer/
Comment: Increase the memory according to AWS Compute Optimizer recommendations --> so we can lower the duration of lambda function to reduce the cost. The ans must be between B & D
Comment: Provisioned Concurrency keeps the Lambda functions initialized and ready to process incoming events, reducing the cold start latency associated with spinning up new execution environments.
Comment: D is correct
Comment: When a large number of messages are in the SQS queue, Lambda scales out, adding additional functions to process the messages. The scale out can consume the concurrency quota in the account. To prevent this from happening, you can set reserved concurrency for individual Lambda functions. This ensures that the specified Lambda function can always scale to that much concurrency, but it also cannot exceed this number. https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html
Comment: When a large number of messages are in the SQS queue, Lambda scales out, adding additional functions to process the messages. The scale out can consume the concurrency quota in the account. To prevent this from happening, you can set reserved concurrency for individual Lambda functions. This ensures that the specified Lambda function can always scale to that much concurrency, but it also cannot exceed this number. https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html
Comment: To reduce compute costs and maintain service latency for customers while using AWS Lambda functions for processing CPU-intensive tasks, you can consider the following strategies: Optimize Lambda Function Configuration: Adjust the memory allocation for Lambda functions to better match the CPU requirements of your workload. Higher memory configurations provide more CPU power. Tune the timeout settings to match the expected processing time of your workload. This prevents unnecessary over-provisioning and reduces costs. Fine-tune the concurrency settings to control the number of concurrent executions based on your workload's characteristics. Use Provisioned Concurrency: AWS Lambda's provisioned concurrency feature allows you to preallocate a number of execution environments to handle incoming requests instantly. This can help reduce cold starts and maintain consistent performance, especially during peak events.
Comment: Reserved concurrency its no charges reduce the computation cost, "latency for its customer" then I'll go for A
Comment: Reserved concurrency guarantees a minimum number of concurrent executions but doesn't inherently improve cold start times like provisioned concurrency.
Comment: need less workload changes and CVEs https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html
Comment: FEWEST changes to the workloads and scan CVE is enough. A looks OK.
Comment: Basic scan looks for Common Vulnerabilities and Exposures (CVEs)
Comment: https://aws.amazon.com/blogs/compute/using-api-destinations-with-amazon-eventbridge/ Amazon EventBridge enables developers to route events between AWS services, integrated software as a service (SaaS) applications, and your own applications. It can help decouple applications and produce more extensible, maintainable architectures. With the new API destinations feature, EventBridge can now integrate with services outside of AWS using REST API calls.
Comment: I agree.
Comment: I'm confused. Both A and B seem to be viable. There is no requirement of cost, complexity, or overhead. :S
Comment: AnswerA EventBridge Schedule will not work as it will allow us to "do something" per schedule. EventBridge rule will allow us to "do something" when event will occur. I think there is no possibility to publish/send job "SUCCEEDED" to AMAZON API Gateway REST API or that we can do anykind of integration with AMAZON API Gateway, hence I would choose A
Comment: Even though option A and B could do the trick and also no statement related to least effort is rquested, EventBridge is dedicated for similar use case. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-destinations.html Plus, it can also handle basic authentication https://aws.amazon.com/blogs/compute/using-api-destinations-with-amazon-eventbridge/
Comment: I think is better to programming a lambda and obtain user and password from Secret Manager... So I think the better solution is B
Comment: EventBridge also store credentials in Secret manager: https://aws.amazon.com/blogs/compute/using-api-destinations-with-amazon-eventbridge/
Comment: Answer should be B.
Comment: Configure Amazon EventBridge Scheduler to match incoming AWS Batch job SUCCEEDED events. Configure an AWS Lambda function to invoke the third-party API using a username and password. Set the Lambda function as the EventBridge rule target.
Comment: A. Configure an Amazon EventBridge rule to match incoming AWS Batch job SUCCEEDED events. Configure the third-party API as an EventBridge API destination with a username and password. Set the API destination as the EventBridge rule target. This option is the most direct and serverless approach to meeting the requirements. Amazon EventBridge can detect the successful completion of the AWS Batch job and trigger actions based on this event. By configuring the third-party API as an API destination with authentication credentials, EventBridge can directly invoke the third-party reporting application without the need for additional services. This approach minimizes complexity and operational overhead.
Comment: Create an AWS Lambda function responsible for invoking the third-party reporting application's HTTP API endpoint. The Lambda function will be triggered by the successful completion of the AWS Batch job.
Comment: AWS Batch sends job status change to EventBridge. https://docs.aws.amazon.com/batch/latest/userguide/batch_cwe_events.html
Comment: look like B
Comment: Pour yourself a cold beer, when you get to this question, its been a very long run
Comment: AnswerC AWS PrivateLink enables you to connect to some AWS services, services hosted by other AWS accounts (referred to as endpoint services), and supported AWS Marketplace partner services, via private IP addresses in your VPC. The interface endpoints are created directly inside of your VPC, using elastic network interfaces and IP addresses in your VPC's subnets. That means that VPC Security Groups can be used to manage access to the endpoints. https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-privatelink.html
Comment: https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/
Comment: I think i go for C, because if you exclude Dirct connect, VPN and GW so only C is available. but create an NLB zo do not want provision a transit GW sounds weird to me
Comment: Private link: Does not require VPC linking: NO Internet Gateway, NO NAT GAteway, No Route table Needs NLB on Service VPC, and ENI on the Customer VPC
Comment: D You can peer both intra-Region and inter-Region transit gateways, and route traffic between them, which includes IPv4 and IPv6 traffic. To do this, create a peering attachment on your transit gateway, and specify a transit gateway. The peer transit gateway can be in your account or a different AWS account. After you create a peering attachment request, the owner of the peer transit gateway (also referred to as the accepter transit gateway) must accept the request. To route traffic between the transit gateways, add a static route to the transit gateway route table that points to the transit gateway peering attachment. https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html
Comment: D does not involve internet. But TGW is unnecessary. A is more simple and clear.
Comment: AWS PrivateLink: AWS PrivateLink enables you to privately access services hosted on AWS in a highly available and scalable manner. With PrivateLink, you can access the vendor's RDS for MySQL instance securely without exposing it to the public internet. The vendor can create a VPC endpoint for RDS within their own VPC, which acts as an entry point for accessing the RDS instance. This endpoint can then be shared with the company. The company can create a VPC endpoint service in their VPC and accept the endpoint connection request from the vendor. This allows the company's resources to communicate with the RDS instance securely through PrivateLink.
Comment: C is correct: https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-securely-publish-internet-applications-at-scale-using-application-load-balancer-and-aws-privatelink/
Comment: Plz commit the previous comment, A involve- Direct connect B involve - peering required same region D involve - uses internet gateway
Comment: No internet gateway XD No Direct connect XC No Peering XB
Comment: Shouldn't it be D?
Comment: YES D transit gateway is like router - u can connect VPCs AND OnPrem. VPCs can be in anuther account or region or org
Comment: I think it required use of internet gateway .
Comment: No, it did not https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html
Comment: (B or C)?-1 = Do we create AMG workspace in a VPC OR do we create AMG workspace without a VPC? AMG is NOT created within a VPC; AMG connects to a VPC. "Currently, you can connect one Amazon Managed Grafana workspace to one VPC endpoint in the same region and same account. However, you can use Virtual Private Cloud peering or AWS Transit Gateway to connect the cross-region or cross-account VPCs, then connect the select the VPC endpoint that's in the same account and same region as your Amazon Managed Grafana workspace." -FAQs (C) is correct.
Comment: (B or C)?-2 = private endpoint OR AWS PrivateLink? The brand-name is more correct. (B or C)?-3 = Configure the private endpoint as a data source OR Set up Amazon RDS as a data source? In the AMG console, after clicking on Data sources, you'll see a list of AWS services (Athena, Redshift etc) NOT network endpoints. After selecting RDS, you can further specify the Region & Resource ID. (B) eliminated. (C) is correct.
Comment: Its B. C is also a valid choice "Not exposing to the internet" is letting me eliminate C
Comment: (B) "a private endpoint" & (C) "an AWS PrivateLink endpoint" do NOT expose traffic to the internet. (A & D) eliminated. "a public endpoint for the RDS database" would "expose the data over the internet"
Comment: B as you need to create Managed Grafana workspace with a VPC for private access https://docs.aws.amazon.com/grafana/latest/userguide/AMG-configure-nac.html
Comment: (B) doesn't say 'with a VPC'; it says "..Grafana workspace IN A VPC." (B) eliminated. (C) is correct.
Comment: https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-managed-grafana-connection-data-sources-hosted-virtual-private-cloud/
Comment: I think is b. Private endpoint sounds like private vpc endpoint, that is equals to privatelink
Comment: I guess they mean C, But again, it's strange... IMO B would also work... There is no requirement for the least effort... Pls, correct me if I'm wrong...
Comment: Once you configure direct connectivity between a Grafana workspace and a VPC, Amazon Managed Grafana creates and manages an elastic network interface (ENI) per subnet to connect to the VPC. This enables the Grafana workspace to connect to data sources within the VPC, such as OpenSearch domains or RDS databases. Additionally, all traffic is now routed through the configured VPC, including alert destination and data source connectivity.
Comment: AWS PrivateLink provides private connectivity between virtual private clouds (VPCs), supported AWS services, and your on-premises networks without exposing your traffic to the public internet. Interface VPC endpoints, powered by PrivateLink, connect you to services hosted by AWS Partners and supported solutions available in AWS Marketplace.
Comment: https://aws.amazon.com/blogs/mt/announcing-private-vpc-data-source-support-for-amazon-managed-grafana/
Comment: B is correct
Comment: cccc ccc
Comment: AWS Glue DataBrew: This is a visual data preparation tool that allows you to clean and normalize data without writing code. It has built-in transformations for common tasks like filtering anomalies, normalizing dates, and generating aggregates. It also provides data lineage and profiling capabilities, which are required by the company. DataBrew Recipes: These are reusable workflows that define the data transformation steps. They can be easily shared with other employees, making it simple to collaborate on data preparation tasks.
Comment: AnswerC AWS Glue DataBrew is a visual data preparation tool that enables users to clean and normalize data without writing any code. Using DataBrew helps reduce the time it takes to prepare data for analytics and machine learning (ML) by up to 80 percent, compared to custom developed data preparation. You can choose from over 250 ready-made transformations to automate data preparation tasks, such as filtering anomalies, converting data to standard formats, and correcting invalid values. https://docs.aws.amazon.com/databrew/latest/dg/what-is.html
Comment: C is correct. https://docs.aws.amazon.com/databrew/latest/dg/recipes.html
Comment: Agree with C
Comment: Should be C
Comment: Both A and C look correct but with the C you pass through the ALB to be redirected to a public IP (so go outside) to come back again through this public IP which is not ideal. The answer A is much cleaner and simplier with a dedicated target group and a listener rule pointing it.
Comment: B: Directly using a public IP address ties the A Record to a specific instance, which is not ideal since replacing the instance would require manually updating the Route 53 record. C: Redirecting to a public IP address of the development instance is similar to option B, and would also require manual updates if the instance changes.
Comment: Public IP is not permanent, so definitely not B and C
Comment: AnswerA, With ALB which will point to appopriate dev group we will be able easy to create HA for dev servers.
Comment: Should be A as it points to the target group for easy replacement etc
Comment: I think its A
Comment: This question is a trap because A is definitely the answer for a Least overhead (ECS + SQS) and in a real life scenario could be good in 99% of cases. However SQS do not implement AMQP (SQS is only a simple queueing system very basic) so we have to use Amazon MQ. In terms of containers EKS will always be a better solution than a manual setup of Docker. Good solution would have been ECS+AmazonMQ not given here Lambda can work with containers, but since there are limitations like 15 minutes limit we can't really consider it as a good solution. So B is the least bad solution.
Comment: AnswerB For me B is a correct solution. In question AMQP is mentioned and Amazon on his doc page about MQ is providing such information: "Amazon MQ is a managed message broker service that provides compatibility with many popular message brokers. We recommend Amazon MQ for migrating applications from existing message brokers that rely on compatibility with APIs such as JMS or protocols such as AMQP 0-9-1, AMQP 1.0, MQTT, OpenWire, and STOMP." I cannot be coincidence that documentation is mentioning about AMQP. https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html
Comment: I'd go for A. Although the ideal solution and least modification would require B, with heavy rework the application can be (most likely) adopted to ECS+SQS. As it is an AWS exam, not a vendor-agnostic SA exam, A will be the correct answer.
Comment: B because only solution with Kubernetes
Comment: Should be B
Comment: In such situation if you had an ALB you would use Cloudfront Since you have a NLB you use AWS Global Accelerator So D.
Comment: AnswerD Usage of Global Accelerator should help here. " Acceleration for latency-sensitive applications Many applications, especially in areas such as gaming, media, mobile apps, ad-tech, and financials, require very low latency for a great user experience. To improve the user experience, Global Accelerator directs user traffic to the application endpoint that is nearest to the client, which reduces internet latency and jitter. Global Accelerator routes traffic to the closest edge location by using Anycast, and then routes it to the closest regional endpoint over the AWS global network. Global Accelerator quickly reacts to changes in network performance to improve your users' application performance. " https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-benefits-of-migrating.html
Comment: Agree with D
Comment: Should be D
Comment: B is correct
Comment: Answer is B
Comment: Explanation: AWS Transfer Family is a fully managed service that allows you to set up SFTP, FTPS, and FTP endpoints for accessing Amazon S3 and Amazon EFS storage. By creating an AWS Transfer Family endpoint, the company can provide vendors with the familiar SFTP interface to upload data directly to Amazon S3 without requiring them to make any changes to their legacy applications. This solution eliminates the need for the company to manage and maintain additional infrastructure such as EC2 instances or file gateways. AWS Transfer Family handles scalability, availability, and security, reducing operational overhead for the company.
Comment: B is correct
Comment: AnswerC " Amazon Comprehend uses natural language processing (NLP) to extract insights about the content of documents. It develops insights by recognizing the entities, key phrases, language, sentiments, and other common elements in a document. Use Amazon Comprehend to create new products based on understanding the structure of documents. For example, using Amazon Comprehend you can search social networking feeds for mentions of products or scan an entire document repository for key phrases. " https://docs.aws.amazon.com/comprehend/latest/dg/what-is.html
Comment: Selected Answer: C amazon comprehend= sentiment analysis
Comment: Selected Answer: C amazon comprehend= sentiment analysis
Comment: Whenever new PDF files are uploaded to the designated S3 bucket, the Lambda function will be triggered to extract insights using Textract and Comprehend.
Comment: When you have words like "sentiment" in a sentence, it's related to Comprehend So C.
Comment: Maybe C?
Comment: Shouldn't it be C?
Comment: A is correct
Comment: real time data => amazon kinesis data stream
Comment: - Amazon Kinesis Data Streams: designed for real-time data ingestion. - Kinesis Data Firehose: can consume data from Kinesis Data Streams and automatically deliver it to Amazon S3. A is the answer.
Comment: each ec2 needs to proceed data separately
Comment: A is best solution, but i think the question is saying "The application needs to ingest real-time data from third-party applications." and the application is run on EC2. so i think we need a solution that works with the application on EC2 for this question?
Comment: DataSync is more suitable for transferring data between on-premises storage systems and AWS, rather than ingesting real-time data. Best solution is A
Comment: Agree with A
Comment: option B is the most operationally efficient solution for handling large data sizes in Amazon DynamoDB.
Comment: B is correct
Comment: AnswerB Compresion of data in DynamoDB is a good idea especially for text data link from forum, but to do that we do not need AWS Lambda if I'm not wrong. In other head Storing big object on S3 and seving URL to it in DynamoDB is one of best practices mentioned by Amazon. Hence we do not know what kind of data we are storing in DB and how big objects will be in the future option B looks like the best solution. https://aws.amazon.com/blogs/database/large-object-storage-strategies-for-amazon-dynamodb/ <<<< Read Option 2 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html
Comment: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html
Comment: Give yourself a pat on the back when you reach this question, its been a long run
Comment: I finally managed to get through the last question, then refreshed the page , and they have added more questions.
Comment: Lambda has 15 mins limit, so A is out. B works, but you have to run highly-available virtual machines or containers waiting for the event to happen. C is the best answer in this question, with AWS Fargate allows you to pay for only what you use and free you from provisioning, configuring, and scaling clusters of Amazon EC2 instances. https://aws.amazon.com/blogs/containers/migrate-cron-jobs-to-event-driven-architectures-using-amazon-elastic-container-service-and-amazon-eventbridge/
Comment: Ans : C https://aws.amazon.com/blogs/containers/migrate-cron-jobs-to-event-driven-architectures-using-amazon-elastic-container-service-and-amazon-eventbridge/
Comment: C because lambda has 15min time limit.
Comment: its either A or C. C looks correct because lambda works for 15 mins and the question says between 1-20
Comment: 3rd party SaaS salesforce integration => Use AWS AppFlow So left C and D Not D because VPC Peering need 2 VPC and 3rd party SaaS does not have a VPC
Comment: AWS PrivateLink: This service enables private connectivity between VPCs and supported AWS services, effectively keeping data off the public internet. It allows secure communication without exposing your data to the internet. Amazon AppFlow: This is a fully managed integration service that simplifies data transfer between SaaS applications (like Salesforce) and AWS services (like Amazon Redshift).
Comment: C is the answer
Comment: Private link for sure
Comment: AnswerC To connect your own VPC with third-party VPC we need to use ProvateLink. AWS PrivateLink is a highly available, scalable technology that you can use to privately connect your VPC to services as if they were in your VPC. You do not need to use an internet gateway, NAT device, public IP address, AWS Direct Connect connection, or AWS Site-to-Site VPN connection to allow communication with the service from your private subnets. Therefore, you control the specific API endpoints, sites, and services that are reachable from your VPC. https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html
Comment: Should be C
Comment: C https://docs.aws.amazon.com/connect/latest/adminguide/integrate-salesforce-tasks.html https://docs.aws.amazon.com/connect/latest/adminguide/vpc-interface-endpoints.html
Comment: i go with A since there is no other better options
Comment: Chose A because optimise storage costs => s3 bucket intelligent tiering
Comment: Since the company is ok with "some application and services changes", then A is definitely the most cost-effective option. D can take up to few hours to complete retrievals.
Comment: EFS Infrequent access -> milliseconds retrieval time, can`t replace with 12hrs for Glacier.
Comment: optimize storage costs with some application and services changes -> Intelligent Tiering
Comment: AnswerA https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html
Comment: B, C, D off. B - Windows C - OpenZFS Costs ~ NFS Costs *3 (optimized mainly for high-performance Data analysis) D - Glacier Standard retrieval: 12 Hrs
Comment: Glacier standard retrieval is 5 hrs and not 12. It is glacier deep archive standard that is 12 hours.
Comment: A is correct
Comment: should be A?
Comment: only ALB can route traffic based on query parameter, NLB cannot. So C
Comment: AnswerC I was thinking that it will be network LB but after checks it occurs that only Application LB is able to redirect/forward traffic based on query string. and for encrypted traffic ACM is needed We recommend that you create certificates for your load balancer using AWS Certificate Manager (ACM). ACM supports RSA certificates with 2048, 3072, and 4096-bit key lengths, and all ECDSA certificates. ACM integrates with Elastic Load Balancing so that you can deploy the certificate on your load balancer. For more information, see the AWS Certificate Manager User Guide. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#rule-condition-types https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html
Comment: Option C - parameter is not a thing NLB can process
Comment: Provision an Application Load Balancer (ALB) in the AWS Cloud. ALB is a Layer 7 load balancer that supports advanced routing features, including path-based routing.
Comment: Target groups are just a group of Ec2 instances. Target groups are closely associated with ELB and not ASG. We can just use ELB and Target groups to route requests to EC2 instances. With this setup, there is no autoscaling which means instances cannot be added or removed when your load increases/decreases.
Comment: Option B: Target Group: it doesn't inherently imply automatic scaling. You would need to manage scaling separately, either manually or through other mechanisms like scheduled actions. Option C: Auto Scaling Group: This ensures that the EC2 instances can automatically scale in or out based on traffic and demand. "The company needs a highly available and automatically scalable solution" => C
Comment: AnswerC highly available and automatically scalable solution = Auto Scale for EC2 in front which we will have ALB and Aurora Server less will give us perfect decoupled solution in which we can increase amount of servers per need and in case of server failure AutoScale will run new EC2 instance
Comment: scalable solution= Amazon Aurora Serverless
Comment: It's C!
Comment: Option C - keywords HA, automatically scalable
Comment: C Is what I will go for
Comment: The anwser can't be A. In addition to other justifications written here in the comments, if the data is copied before enabling encryption, this data will not be encrypted.
Comment: B is the Answer
Comment: It's said should be encrypted within S3 not before so A its correct
Comment: Me: Does SSE-S3 allow custom key rotation scheduling? Gemini: No, SSE-S3 does not allow for custom key rotation scheduling. Gemini: If you require more granular control over key rotation, you should consider using Server-Side Encryption with AWS KMS (SSE-KMS)
Comment: AnswerB Looks like key rotation is only possible when KMS is in use. If we will use AWS managed keys Rotation is forced and if we will not provide any specifications regarding rotation time for key, KMS will rotate key every 365days. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt
Comment: If you see rotation, SEE-SE is out
Comment: SSE-S3 does not rotate the key EVERY YEAR and it is not fit the requirement
Comment: This question is flawed. SSE-S3 is not SSE-KMS, so it will not automatic rotation every year, only KMS will. (check link below) But the question says "LEAST operational overhead", I think it want us to choose SSE-S3, so I will pick option A.
Comment: SSE-S3 is the simplest method to use as encryption keys are handled and managed by AWS. But is not what we're saying about "AWS managed key", so it will not automatic rotation every year. https://catalog.us-east-1.prod.workshops.aws/workshops/aad9ff1e-b607-45bc-893f-121ea5224f24/en-US/s3/serverside/sses3 "AWS managed keys" are "KMS keys" in your account. And will (required) automatic rotation every year. https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt
Comment: there are several pages (not the official aws page) said its 365 days. But, the official page does not mention about the rotation period is 365 days
Comment: SSE-KMS is similar to SSE-S3 but comes with some additional benefits over SSE-S3. And SSE-KMS is "AWS managed key." So it will (required) automatic rotation every year. https://catalog.us-east-1.prod.workshops.aws/workshops/aad9ff1e-b607-45bc-893f-121ea5224f24/en-US/s3/serverside/ssekms Difference between AWS S3 Bucket Encryption SSE-C , SSE-S3, SSE-KMS. https://awstip.com/5-minutes-to-aws-s3-bucket-encryption-sse-c-sse-s3-sse-kms-e2fb07b05cb3
Comment: I will go for B. A it's somehow wrong for coupl of reason: 1- Encription must be specified before to transfer the data (even if from 1/23 it's automatically for every bucket, so actualy make no sense to specify it) 2- SSE-S3 keys are regurarly rotated but aws do not specify when (https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html ) IMO if need to be compliance with rotation period better use Costumer managed key as stated from aws support in 01/2024 https://repost.aws/questions/QUES_1VN01TU-eRSO3LXergA/s3-managed-key-sse-s3-rotation-period
Comment: Considering the statement "the LEAST operational overhead" we could go for option A due to the following AWS managed keys capabilities https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys
Comment: Option A
Comment: From May 2022 the scheduled rotation is 1 year (SSE-S3)
Comment: A is wrong because you need to set the encryp options before send the data to S3.
Comment: It's B.
Comment: A is correct because SSE-S3 help decrease the management
Comment: B is the right one
Comment: Same with Question #202, I'll go with B but not sure
Comment: "continue to manage users and groups that are in the on-premises Active Directory" I go for B
Comment: AnswerB AWS Directory Service lets you run Microsoft Active Directory (AD) as a managed service. AWS Directory Service for Microsoft Active Directory, also referred to as AWS Managed Microsoft AD, is powered by Windows Server 2019. With AWS Managed Microsoft AD, you can run directory-aware workloads in the AWS Cloud, including Microsoft SharePoint and custom .NET and SQL Server-based applications. You can also configure a trust relationship between AWS Managed Microsoft AD in the AWS Cloud and your existing on-premises Microsoft Active Directory, providing users and groups with access to resources in either domain, using AWS IAM Identity Center. https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html
Comment: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html
Comment: Same with Q-28
Comment: Aurora only have: -> Standard -> I/O-Optimized (need optimise storage thats why i chose this)
Comment: Answer is D
Comment: AnswerD For Aurora we have 2 storage type/options: A - Standard B -- I/O-Optimized hence answers B and C options are incorrect. Because customer inform us that there will be a big amount of traffic for their application I would go with I/O-Optimized. Maybe we are giving more $$ per GB-month but we are not paing for I/O operations/request. https://aws.amazon.com/rds/aurora/pricing/ In general question is not precise and it is hard to say which option will be more beneficial (cost effective)
Comment: Aurora I/O-Optimized – Improved price performance and predictability for I/O-intensive applications. You pay only for the usage and storage of your DB clusters, with no additional charges for read and write I/O operations.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html#aurora-storage-type
Comment: D is more suitable
Comment: I would choose D
Comment: I think A is true answer
Comment: https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/ Aurora I/O-Optimized offers up to 40% cost savings for I/O-intensive applications where I/O charges exceed 25% of the total Aurora database spend.
Comment: Agree with haci
Comment: The traffic load is not defined well enough to decide which storage type to use. General Purpose (SSD) storage suits many workloads, including small to medium-sized databases and it is cost-effective. Provisioned IOPS (PIOPS) storage is the highest-performing option available for RDS instances. With Provisioned IOPS storage, you can provision a specific amount of IOPS (input/output operations per second) based on your application's needs. But here we don't know the amount of requests. So since the question is asking for cost-effective I'll go with C
Comment: Security Hub: assess your AWS environment against security industry standards and best practices.
Comment: security industry standards => security hub
Comment: NIST, PCI DSS Compliance + AWS accounts -> Security Hub
Comment: https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
Comment: selected A because only option that don't violate the "need immediate access"
Comment: "data that is accessed randomly" = S3 Intelligent-Tiering storage class.
Comment: AnswerA The Amazon S3 Intelligent-Tiering storage class automatically stores objects in three access tiers. One tier is optimized for frequent access, one lower-cost tier is optimized for infrequent access, and another very low-cost tier is optimized for rarely accessed data. For a low monthly object monitoring and automation charge, S3 Intelligent-Tiering monitors access patterns and automatically moves objects to the Infrequent Access tier when they haven't been accessed for 30 consecutive days. After 90 days of no access, the objects are moved to the Archive Instant Access tier without performance impact or operational overhead. https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html
Comment: File accessed randomly by multiple teams = intelligent tiering
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-managing.html
Comment: everytime i see some social network related qns i immediately look for amazon neptune
Comment: Neptune: A Graph database stores nodes and relationships instead of tables or documents
Comment: https://docs.aws.amazon.com/neptune/latest/userguide/notebooks-visualization.html
Comment: Neptune automatically scales storage and compute resources based on workload demands, ensuring optimal performance even as the dataset grows over time.
Comment: Not A because for individual conenction not company Not B because overkill, usually for high bandwidth, but qns clearly stated no need for high bandwidth and handle small traffic Not C because bastion host for remote access D because ideal for small amt of traffic
Comment: AnswerD AWS site-to-site VPN is the best solution here. https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
Comment: You can enable access to your remote (on-prem) network from your VPC by creating an AWS Site-to-Site VPN (Site-to-Site VPN) connection and configuring routing to pass traffic through the connection.
Comment: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
Comment: Answer C We need Transfer Family SFTP enabled server (with SFTP endpoint). Additiionally AWS Directory Service with AD connector to reach on-premises AD for authentication and authorization. https://docs.aws.amazon.com/transfer/latest/userguide/getting-started.html https://docs.aws.amazon.com/transfer/latest/userguide/create-server-sftp.html https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html
Comment: what is the difference between C and D ???
Comment: AD Connector - when the company already had the Active Directory, you need a connector
Comment: 1. Create one or more AWS Managed Microsoft AD directories using the AWS Directory Service console. 2. Use the Transfer Family console to create a **server** that uses **AWS Managed Microsoft AD** as its identity provider. 3. Add access from one or more of your AWS Directory Service groups. 4. Although not required, we recommend that you test and verify user access.
Comment: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html
Comment: SNS and Message Filtering - With SNS, message filtering allows you to control which subscribers receive messages based on attributes. However, the entire message is sent to each subscribed Lambda function; only those that match the filter criteria are processed. EventBridge and Input Transformation - EventBridge enables you to define rules that transform or modify events before they reach their targets. This allows you to customize the event payload, ensuring each validation step receives only the relevant information. "The company wants to ensure that each validation step Lambda function has access to only the information from the order event that the function requires." Therefore, C is the answer.
Comment: Event-driven Architecture + Each validation step needs ONLY a subset of the order EVENT created. Best way to transform this order even is EB Transformer.
Comment: Answer C I wasn't sure but looks like EB with Input Transformation will allow for sending data which were choosed per destination https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes-input-transformation.html
Comment: not B because SNS cannot make messages manipulation, the option "message body filtering" will make discard or forward the FULL message if there is a matching field: https://docs.aws.amazon.com/sns/latest/dg/sns-message-filtering.html C - eventbus instead can manipulate event: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html D - Works, but too much operation IMO
Comment: Why can't it be B?
Comment: It is D. It is one order event, not "events from many sources" The main lambda parse the info to pieces, then makes synchronous invocations of the validation step Lambda functions on separate threads, and wait them to complete.
Comment: IMO, C "An event bus is a router that receives events and delivers them to zero or more destinations, or targets. Event buses are well-suited for routing events from many sources to many targets, with optional transformation of events prior to delivery to a target."
Comment: Option C
Comment: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html
Comment: real-time reports - > read replica
Comment: caused by users generating different real-time reports -> read replica
Comment: Answer C Any replica of Amazon Aurora Db will be read-only replica (even backup one). Option C is better then D because we will use multiple replicas which when used will signicially allow to increase performance for creating reports. In the same time no write operation should be affected. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html
Comment: AnswerC Amazon S3 interface endpoint seems to be the best and only option as we are forced to use Private IP addressation. Interface endpoints for Amazon S3 Your network traffic remains on the AWS network. Use private IP addresses from your VPC to access Amazon S3 Require endpoint-specific Amazon S3 DNS names Allow access from on premises Allow access from a VPC in another AWS Region by using VPC peering or AWS Transit Gateway https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3
Comment: A. https://repost.aws/knowledge-center/s3-bucket-access-direct-connect
Comment: This article says "Use a private IP address over Direct Connect (with an interface VPC endpoint)" - C
Comment: A. public VIF is the way you can connect on-premise with S3 via DirectConnect
Comment: B Need internet A,D doesn't conect to the s3 IMO, C is the solution for this question.
Comment: Option C
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html
Comment: 53 with multivalue is the best option for this case Multivalue answer routing lets you configure Amazon Route 53 to return multiple values, such as IP addresses for your web servers, in response to DNS queries. You can specify multiple values for almost any record, but multivalue answer routing also lets you check the health of each resource, so Route 53 returns only values for healthy resources. It's not a substitute for a load balancer, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve availability and load balancing.
Comment: C and D are wrong because need serve traffic across both region. B seems correct
Comment: A - Doesn't provide health check C and D - Only work within a single zone.
Comment: Yes, is the option b.
Comment: Option B
Comment: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-multivalue.html
Comment: cross many EC2 instances and across multiple Availability Zones = EFS
Comment: "files must be available across many EC2 instances" means need some sort of shared system immediately i look for EFS
Comment: my question is, why not A? I am fine with C
Comment: cross many EC2 instances and across multiple Availability Zones = EFS
Comment: SSL/Certificate => encrypt in transit, so A and C are wrong. so i feel the answer is between B and D.
Comment: Encryption should be KMS, SSL is for transit not at rest... Even though the question never mentioned any EBS volumes whatsoever, I would still go for D....
Comment: Amazon RDS relies on Amazon EBS volumes for storage. By configuring Amazon EBS encryption, the underlying storage volumes are encrypted.
Comment: answer:C
Comment: answer:C
Comment: without internet => gateway endpoints
Comment: Answer C "The company wants to access Amazon S3 without traversing the internet." so we cannot use any NAT like in answer A & B. Transit Gateways is allowing reach Direct Connect or VPN connection from VPC. Hence C need to be a good answer
Comment: why not D? i don't understand
Comment: Complexity and cost are high and too complicated for scenarios where only S3 access is required.
Comment: The Key words are "Without traversig the internet". So, the awser is C. https://docs.aws.amazon.com/pt_br/vpc/latest/privatelink/gateway-endpoints.html
Comment: By provisioning a gateway endpoint for Amazon S3 in the VPC, you enable the Lambda function running in the private subnets to access S3 directly without needing to go through the NAT instance or traverse the internet. This solution helps alleviate the network congestion issue and reduces latency since the traffic between Lambda and S3 stays within the AWS network. Additionally, updating the route tables of the subnets to route S3 traffic through the gateway endpoint ensures that the Lambda function can seamlessly communicate with S3 without encountering timeouts caused by network saturation on the NAT instance.
Comment: NAT gateways are highly available and can automatically scale up to meet increased traffic demands.
Comment: And uses the internet... So it can be a good solution, but not here, as: Without traversing the internet
Comment: A https://aws.amazon.com/about-aws/whats-new/2015/12/introducing-amazon-vpc-nat-gateway-a-managed-nat-service/
Comment: I see TCP/UDP related connection => AWS Global accelerator
Comment: Looks like the question is very old, but before the right answer was Cloudfront. Now AWS says that "All RTMP workloads should begin migrating to a standard CloudFront Web distribution and use one of several HTTP streaming protocols such as HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), Microsoft Smooth Streaming (MSS), or HTTP Dynamic Streaming (HDS)." https://repost.aws/questions/QUoUZgHZh7SEWlnQUPlBmVNQ/announcement-rtmp-support-discontinuing-on-december-31-2020
Comment: AnswerB We can eliminate C and D, A is for Web apps hence B should be ok additionally https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-how-it-works.html
Comment: Upload, TCP > AWS Global Accelerator
Comment: Last time I made it to the last question, they added more questions 2 mins later.
Comment: They added 40 more questions today😔
Comment: HTTP(S) -> Cloudfront Other TCP -> AWS Global Accelerator
Comment: So the answer is B :)
Comment: Can't believe I finally made it to the last question. Good luck to everyone!
Comment: OptionB
Comment: Where are questions 841-848? I am I missing something?
Comment: B makes sense not A since CloudFront is CDN
Comment: Global accelerator provides the acceleration for TCP
Comment: AnswerB The problem is that we need to choose best solution which is most cost-effective and have minimal administrative effort. Glacier is the best choice for 1st look, but there is one problem with that solution. From what I know there is no easy way to copy from EBS to Glacier and additionally curent strategy is to make incremental snapshots. To copy file from EBS to (s3) Glacier we would need to run linux to which we will mount EBS and we will need copy everything to S3 and then move to glaceir deep archive. And what is more you will have only incremental snapshot. Hence every solution which will say copy/move to S3 is not minimal administrative effort. Not mentionig that you will not have full snapshot https://repost.aws/questions/QUsaCoBAfbR6WMOz6BH3vqHA/move-ebs-to-glacier
Comment: I first thought the same, but NO: "Which solution will meet these requirements MOST cost-effectively?" There is no mention to "operational overhead" or "minimal changes", etc. The question is asking purely "what is cheaper". So, A is the answer. "We charge you $0.0125 per GB-month of stored data and $0.03 per GB retrieved. " "All Storage / Month $0.0036 per GB S3 Glacier Deep Archive *** - For long-term data archiving that is accessed once or twice in a year and can be restored within 12 hours"
Comment: If we consider both cost and administrative effort more closely: EBS Snapshots Archive may be easier to manage but could incur higher costs over 7 years compared to S3 Glacier. S3 Glacier, despite its complexity for initial transfers, could end up being more cost-effective in the long run, especially for large data volumes. Ultimately, if minimizing costs is a primary concern and the organization can handle the initial complexity of transferring snapshots, using S3 Glacier (Option A) could still be worth considering. So, while Option B is easier, if cost is a significant factor, Option A might be the better choice despite the additional administrative effort involved. It's a trade-off that depends on the organization's priorities regarding cost and operational simplicity.
Comment: "We charge you $0.0125 per GB-month of stored data and $0.03 per GB retrieved. " https://aws.amazon.com/blogs/aws/new-amazon-ebs-snapshots-archive/ "All Storage / Month $0.0036 per GB S3 Glacier Deep Archive *** - For long-term data archiving that is accessed once or twice in a year and can be restored within 12 hours" https://aws.amazon.com/s3/pricing/ 2nd time reviewing this question and, yeah, "A" is the option that better meets the "cost" requirement.
Comment: Keyword here is cost. S3 Glacier deep archive is significantly cheaper than keeping snapshots in the EBS snapshot standard tier or even the EBS Snapshots Archive.
Comment: A is correct answer
Comment: Choose EBS Snapshot Archive when: Data is associated with EBS volumes. You need to maintain point-in-time copies of your EBS volumes. You require faster restore times than S3 Glacier Archive. You need to comply with regulations requiring EBS snapshot retention.
Comment: Option (B) is incorrect due to the following: Archiving is recommended for monthly, quarterly, or yearly snapshots. Archiving daily incremental snapshots of a single volume can lead to higher costs when compared to keeping them in the standard tier. https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html
Comment: I would like to vote "A". we have to focus on the cost as per question.
Comment: (A) is incorrect. Although S3 Glacier Deep Archive is cheaper, to copy the monthly EBS snapshot to S3 would leave a container filled with incremental snapshots that would need to be first assembled into a full snapshot before it could be available. Amazon EBS Snapshots Archive stores full snapshots ensuring 'that data is available with minimal administrative effort'.
Comment: looks like an archivesituation for me https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html The option A is actually cheaper, but i do not like the word copy, and as far as i know there is no way, without writing custom code, to automate che move of snapshot to glacier and i think that the purposu of this question is to show that you know that there is the snapshot archive option
Comment: B , there is not admin effort for bringing it back
Comment: Daily and Monthly Snapshots: Keeping daily snapshots in the EBS snapshot standard tier for 1 month ensures that recent backups are readily available for quick recovery. Incremental Snapshots: Using incremental snapshots reduces storage costs by only capturing and storing the changes made since the last snapshot. This approach minimizes the amount of data transferred and stored, optimizing costs while ensuring that backup data is up to date. Minimal Administrative Effort: This solution requires minimal administrative effort as it leverages existing EBS snapshot functionality and does not require manual intervention to move snapshots to other storage classes or manage additional backup policies.
Comment: nope I am wrong B is correct
Comment: When archive a snapshot, the incremental snapshot is converted to a full snapshot. You need to store the full snapshot every month. 12 FULL snapshots for a year. 7 years would be 84 full snapshots (350TB). The cost would be much more than S3 Deep archive ### When you archive a snapshot, the incremental snapshot is converted to a full snapshot, and it is moved from the standard tier to the Amazon EBS Snapshots Archive tier (archive tier). Full snapshots include all of the blocks that were written to the volume at the time when the snapshot was created. ### https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html
Comment: it's not possibile to automate the moving from ebs to ebs archive so i'll go with A, that also cost less
Comment: https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html
Comment: How much does EBS snapshots archive cost? Pricing and billing. Archived snapshots are billed at a rate of $0.0125 per GB-month. For example, if you archive a 100 GiB snapshot, you are billed $1.25 (100 GiB * $0.0125) per month. What is the cost of Glacier? Even though uploading data to Amazon S3 Glacier is free, there is a pricing method for upload requests, which is $0.03 per 1,000 requests. Transferring data out of S3 Glacier to the same region is free; however, there is a cost for transferring data to a different region. • $0.0036 per GB / Month
Comment: By default, when you create a snapshot, it is stored in the Amazon EBS Snapshot Standard tier (standard tier). Snapshots stored in the standard tier are incremental. This means that only the blocks on the volume that have changed after your most recent snapshot are saved. Some typical use cases include: Archiving the only snapshot of a volume, such as end-of-project snapshots Archiving full, point-in-time incremental snapshots for compliance reasons. Archiving monthly, quarterly, or yearly incremental snapshots. https://docs.aws.amazon.com/ebs/latest/userguide/ snapshot-archive.html
Comment: Maybe B? https://repost.aws/knowledge-center/ebs-copy-snapshot-data-s3-create-volume
Comment: i know S3 Glacier Deep is much cheaper than S3 Standard IA in optionD but A also says Copy, not move. does it mean it will still keep a copy on the snapshot on EBS? i forgot to vote D
Comment: AWS backup is the only managed service so D
Comment: A is oke but it says "'AWS managed service solution" So I go for D
Comment: (A,B,C) are eliminated. They are NOT managed service solutions. (D) is correct. 'AWS Backup offers a cost-effective, FULLY MANAGED, policy-based service that simplifies data protection at scale.' https://aws.amazon.com/getting-started/hands-on/amazon-efs-backup-and-restore-using-aws-backup/
Comment: A is cheaper and less complicated to impliment compared to D
Comment: Aws backup is not replicating. Efs replication is and it's managed in that you configure it and then it does the replication - no further actions required. It's also cheapest since it's free, you just pay for data transfer and storage https://docs.aws.amazon.com/efs/latest/ug/efs-replication.html https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/
Comment: AnswerD I think the most cost effective would solution presented in C, but hence in question it's clearly wrote that we should use AWS Managed Services Solution, hence I think we have no other choice then to choose AWS backup (Option D)
Comment: https://docs.aws.amazon.com/managedservices/latest/userguide/features.html
Comment: A: Replication is available in all AWS Regions in which EFS is available. To use replication in a Region that is disabled by default, you must first opt in to the Region. For more information, see Managing AWS Regions in the AWS General Reference Reference Guide. If you later opt out of a Region, Amazon EFS pauses all replication activities for the Region. To resume replication activities for the Region, you need to again opt in to the AWS Region. https://docs.aws.amazon.com/efs/latest/ug/efs-replication.html
Comment: A. you can replicate to another Region
Comment: NOTA: EFS-to-EFS backup: You must deploy this solution in the same AWS Region as your source Amazon EFS Folesystem Not B, C: Not a managed AWS Solution D: AWS backup will do the job, and is managed service.
Comment: To me "an AWS managed service solution" automatically translates to AWS Backup. ...Can't say if this is cheaper than EFS replication tho.
Comment: To replicate data from an Amazon Elastic File System (EFS) file system to another AWS Region, the MOST cost-effective solution would be to use EFS Replication. Here's why: EFS Replication: EFS Replication allows you to natively create a copy of your file system in an AWS Region or Availability Zone (AZ) of your choice. It automatically and transparently copies your data from the source file system to the destination, maintaining an RPO (Recovery Point Objective) of 15 minutes for most file systems. This solution is specifically designed for replicating EFS data across Regions, ensuring data resilience and protection. There are no additional costs for using replication failback, and you pay for the usual replication and file system changes as described in Amazon EFS pricing12. EFS Replication is available in all AWS Regions where EFS is available1.
Comment: But it is not a managed service
Comment: AnswerC I would de-couple as many elements as possible with appopriate redundancy (HA), hence Auto-Scale in 2 AZ for EC2, Database in Multi-AZ and ALB infront of EC2. It will allow to increase amount of servers in case of need and will prevent from service unavailability in case if something fail ;)
Comment: yes ''C'' but it was better if it says Amazon RDS for Microsoft SQL Multi-AZ. any ways
Comment: Agree, Options Only C has auto scaling and RDS, and RDS support sql server, so it could only be C
Comment: only c
Comment: HA - option C
Comment: Option a
Comment: Operational efficiency, script need to be run every time, and send email need to use SNS, so it should be C
Comment: AnswerC Deploying full instance is an overkill. Lambda should be enough + SNS to sent email. And it should be quite cheap
Comment: SNS for sending mails Lambda to scan the database + send the message to the SNS topic. Using a script on a EC2 will add maintenance on both the EC2 and the script + cronjobs are not reliable and can be hard to monitor properly. SO answer C !
Comment: SNS for sending mails Lambda to scan the database + send the message to the SNS topic. Using a script on a EC2 will add maintenance on both the EC2 and the script + cronjobs are not reliable and can be hard to monitor properly.
Comment: the company anticipates a spike in traffic during a holiday each year -> schedule action
Comment: AnswerB https://medium.com/@damadhav/aws-scaling-reactive-vs-proactive-vs-predictive-2701ad6d48c9
Comment: it says proactively
Comment: it needs a scheduled action for the yearly holiday peak traffic
Comment: Since we know when we will have a peak of activity. A scheduled scaling is a good idea.
Comment: selected answer: B it needs a scheduled action for the yearly holiday peak traffic
Comment: The answer IS A
Comment: AnswerA "In Secrets Manager, you can set up automatic rotation for your secrets." https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html
Comment: A. AWS Secrets Manager
Comment: Option A (Store the password in AWS Secrets Manager and enable automatic rotation on the secret) is the best solution. It meets the requirements with the least operational overhead by leveraging built-in features specifically designed for managing and rotating database credentials securely.
Comment: AnswerB BYOL + third-party features/applications = RDS Custom. Hence customer is using Oracle so we should use RDS customer for Oracle https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-custom.html https://aws.amazon.com/blogs/aws/amazon-rds-custom-for-oracle-new-control-capabilities-in-database-environment/ https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-custom-oracle.html
Comment: Amazon RDS Custom for Oracle by using native tools= to support the third-party features.
Comment: B IS suitable for this use case : thé use or BYOL and the use or third party features with privileged access
Comment: Considering the requirements and the need to use Oracle Database features with privileged access and BYOL, Option B (Migrate the database to Amazon RDS Custom for Oracle by using native tools. Customize the new database settings to support the third-party features) is the most cost-effective and suitable solution. It allows for significant customization needed to accommodate specific third-party features while leveraging existing Oracle licenses.
Comment: AnswerB AWS native tool that will support EC2, RDS and DynamoDB = AWS Backup https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-supported-services.html
Comment: Automate backups = AWS Backup
Comment: Centralized management of backups == AWS Backup
Comment: Visualize your AWS Infrastructure with Amazon Neptune and AWS Config https://aws.amazon.com/blogs/database/visualize-your-aws-infrastructure-with-amazon-neptune-and-aws-config/ Using Amazon Neptune for Security Graphs https://aws.amazon.com/neptune/security-graphs-on-aws/#:~:text=Using%20Amazon%20Neptune%20for%20Security%20Graphs
Comment: Option B is very tough to impliment for such a simple usecase.
Comment: AnswerB Neptune is the only Graph database from all options which seems to be most suitable. I'm not sure about SPARQL but hence Neptun is the best option hence SPARQL should be to. https://docs.aws.amazon.com/neptune/latest/userguide/intro.html
Comment: Option B (Use Amazon Neptune to store the data. Use SPARQL to query the data) is the most suitable choice. Neptune is purpose-built for storing and querying graph data, making it a natural fit for representing and querying the complex relationships inherent in an IT infrastructure map. Additionally, SPARQL is a powerful and efficient query language for graph databases, facilitating quick identification of security risks.
Comment: Using Amazon Neptune with SPARQL, a query language for graph databases, allows the security team to easily query the data in the IT infrastructure map to identify security risks. SPARQL is specifically designed for querying graph data and allows for complex queries to traverse relationships between resources efficiently.
Comment: (A,B,D) eliminated. Aurora instances & Amazon RDS use On-Demand or Reserved INSTANCES. These are more expensive than a serverless solution. (C) is correct. Amazon Aurora Serverless automatically starts up, shuts down & scales capacity up or down based on your application's needs; you pay only for capacity consumed.
Comment: Yes but its asking for the most cost effective. B would cause frustration for developers if it was terminated unexpectedly. The answer should be C so developers can easily access when they are needed and auto scales based on demand
Comment: You're correct for the wrong reasons. An instance being 'terminated unexpectedly' & it having 'easily access" are qualities related to high availability & not cost effectiveness. (B) is wrong because it's more $$$.
Comment: when i see "managed PostgreSQL databases", i immediately look for serverless
Comment: I think the answer correct is B as the database should be managed by the developer and Each developer needs a separate DB.
Comment: Requirement: Each developer needs a separate DB. In a cluster, DB is shared among developers.
Comment: Guys, listen to the question, each developer -> a separate managed PostgreSQL DB. this is the task. Then Most cost-effective comes. If you get a cheaper thing that does not fulfull the task, you are wrong. Question: Can each developer get a separate DB for himself from the cluster?
Comment: Answer C: We know we require Service Catalog. This option provides workflow no how it works
Comment: AnswerC Using Aurora Serverless solution + AWS Service Catalog features seems to be a good idea https://aws.amazon.com/rds/aurora/serverless/ https://aws.amazon.com/servicecatalog/features/
Comment: Only option B can have limited size database
Comment: "when creating your Aurora database cluster, specify the desired range of database capacity or use the defaults, and connect your applications." This way we limit the capacity that we pay for. https://aws.amazon.com/rds/aurora/serverless/
Comment: Aurora Serverless = inicia, encerra e escala a capacidade automaticamente de acordo com as necessidades. AWS Service Catalog = catalogo de serviços que usuarios podem utilizar, dentro das configurações permitidas. https://aws.amazon.com/pt/rds/aurora/serverless/ https://aws.amazon.com/pt/servicecatalog/
Comment: I thin is c
Comment: With AWS Service Catalog, you can meet your compliance requirements while making sure your customers can quickly deploy the cloud resources they need.
Comment: website content must be in sync with all EC2 instances, so use EFS
Comment: B is the answer
Comment: AnswerB Looks like this is the only reasonable solution from all presented
Comment: CMS is usually EFS
Comment: AnswerA Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior across your AWS environment. https://aws.amazon.com/guardduty/features/
Comment: Gard duty for automatic treat detection
Comment: Threat detection means guarduty
Comment: Malicious or suspicious activity - think of GuardDuty
Comment: Using IAM database authentication and associate a role with the EC2 instances is the least operational effort.
Comment: AnswerC Customer would like to not manage password rotation from my understanding, hence A and B are not the best solution here. I don't think we can associate IAM user with EC2 instance, but we can associate IAM role. In summary C https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html
Comment: Have to use east-1 region for ACM, and it should be public SSL/TLS for domain, so it should be C
Comment: AnswerC Per AWS "Public SSL/TLS certificates provisioned through AWS Certificate Manager are free. You pay only for the AWS resources you create to run your application." https://aws.amazon.com/certificate-manager/pricing/?nc=sn&loc=3 But hence AWS is recommending to use US east 1 I think I would go with C Note We recommend that you use ACM to provision, manage, and deploy SSL/TLS certificates on AWS managed resources. You must request an ACM certificate in the US East (N. Virginia) Region. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html
Comment: browsers trust public certificates automatically by default > C or D To use an ACM certificate with Amazon CloudFront, you must request or import the certificate in the US East (N. Virginia) region [Nowhere is it stated why is this though...] > C
Comment: The certificate has to be public. The certificate has to be issued in us-east-1: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html "To use an ACM certificate with CloudFront, make sure you request (or import) the certificate in the US East (N. Virginia) Region (us-east-1)."
Comment: https://aws.amazon.com/certificate-manager/pricing/ AWS Certificate Manager Pricing Public SSL/TLS certificates provisioned through AWS Certificate Manager are free. You pay only for the AWS resources you create to run your application. If you manage AWS Private Certificate Authority (CA) through ACM, refer to the AWS Private CA Pricing page for more details and examples.
Comment: It is c
Comment: Should be c, it is a public certificate
Comment: CloudFront should have a private cert and browser use public cert aiming to achieve non-repudiation. Ans should be A
Comment: This should be C. Private CA is not free
Comment: Why not D.evrn option D is public CA
Comment: AnswerD When using CLI to create presigned URL we can setup 7days (max) for URL expiration from the time of creation. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
Comment: Pre-signed URLs are used to provide short-term access to a private object in your S3 bucket. They work by appending an AWS Access Key, expiration time, and Sigv4 signature as query parameters to the S3 object.
Comment: Tightly coupled, low-latency,hpc - cluster placement group
Comment: I THINK IT'S C,D
Comment: tightly coupled node-to-node communication -> placement group
Comment: AnswerA I was thinking it will be D but after some research I think it will be A https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
Comment: he key word here is ''tightly coupled node-to-node communication'' which means we need to Configure the EC2 instances in a cluster placement group.
Comment: all points to a cluster placement group
Comment: The answer should be A.
Comment: AnswerC Maximum resilient solution will be to have 2 independet connections to AWS from each location (maximum redundancy)
Comment: The most resilient is C
Comment: Redundant Connections: Having two Direct Connect connections from each data center provides redundancy in case one connection fails. Diverse Direct Connect Locations: Terminating the connections at two different Direct Connect locations further eliminates the risk of a single point of failure due to issues at a specific location. Separate Devices: Using separate devices at each Direct Connect location adds another layer of redundancy, preventing a single device failure from impacting connectivity.
Comment: "On-Demand DB instances that have high utilization" High Utilization = no point in checking for Idle instances On-Demand = it makes sense to replace On-demand for Reserved instances.
Comment: https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html
Comment: I THINK IT'S C,D
Comment: https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html
Comment: AnswerAC We have On-Demand instances of RDS. If DB is used very often then it can occur that using Reserved Instrance can bring some $$ savings. It is mentioned in AWS docs :) https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html#amazon-ec2-reserved-instances-optimization
Comment: Instances are running On-Demand, they need to check to see if they can save money by switching the reserved instances from on-demand An important part of using AWS involves balancing your Reserved Instance (RI) purchase against your On-Demand Instance usage. This check provides recommendations on which RIs will help reduce the costs incurred from using On-Demand Instances.
Comment: Cost Optimization: By providing actionable recommendations, Trusted Advisor assists you in identifying areas of overspending and underutilization, like idle RDS DB instances or underused EBS volumes, leading to significant cost savings.
Comment: Please check with question 308. It should run in management account and review the Trusted Advisor check for Amazon RDS Idle DB Instances.
Comment: I correct myself the answer should be AC as the DB can be switch to on-demand rather than reserved and it would save save the cost.
Comment: https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html#amazon-rds-reserved-instance-optimization
Comment: Option A,E
Comment: i dont think AWS Compute Optimizer work with RDS
Comment: use Trusted advisor on management account
Comment: https://docs.aws.amazon.com/awssupport/latest/user/organizational-view.html
Comment: AnswerA I think only option A have any sense. It is cheap (no cost), it is secure (traffic is not going to public network). https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
Comment: Aws gateway will have no cost because the trafic will stay on aws infrastructure.
Comment: Gateway endpoint will minimize data transfer costs
Comment: A- gateway endpoint for S3
Comment: gateway endpoint for Amazon S3
Comment: Gateway endpoint is free https://digitalcloud.training/vpc-interface-endpoint-vs-gateway-endpoint-in-aws/.
Comment: high volume of write operation -> Provisioned IOPS SSD storage
Comment: Answer A For sure we cannot choose generar purpose IOPS SSD hence I would choos provisioned one. addtionally it is a good idea to monitor performance with CloudWatch and adjust setup(provisioned IOPS) if there will be a need.
Comment: The most effective strategy for coping with that limit is to supplement disk-based databases with in-memory caching (Elasticache for Redis, Write-through strategy) I'd go for B...
Comment: If it were changes to existing data, maybe. The scenario specifically says data imports. Going with "A".
Comment: A or B. Can't be B because there is high volume of write no need for Elasticache
Comment: Amazon RDS for MySQL DB instance with Provisioned IOPS SSD storage
Comment: "ensure that third parties do not have access to the data before the data is encrypted and sent to AWS"
Comment: "Amazon S3 managed encryption key" (SSE-S3) is a server-side encryption. Therefore it is not a client-side encryption. To encrypt the data before sending to S3, it has to be client-side encryption.
Comment: Must encrypt the data on client side before uploading it to S3
Comment: Its B "Amazon RDS performs a full daily backup of your data during a backup window that you define when you create the DB instance. You can configure a retention period of up to 35 days for the automated backup."
Comment: By default, Amazon RDS creates and saves automated backups of your DB instance securely in Amazon S3 for a user-specified retention period. You can set the backup retention period from 1 to 35 days. The maximum retention period currently available for automated snapshots is 35 days. When automated backups are turned on for your DB Instance, Amazon RDS automatically performs a full, daily snapshot of your data and captures transaction logs.
Comment: Read Replica for multiple users access and read the data
Comment: Answer C, wording is that read queries are slowing down write queries -> we need to optimize for read queries -> we need to add read replicas. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html#Aurora.Managing.Performance.ReadScaling
Comment: write queries=>High performance of read & Write Dynamo, I think DAX is a better solution.
Comment: Dynamo is NoSQL...
Comment: AnswerC A - We can create only RO replica of DB hence this is not possible. D - Redshift is not for a DB from my understanding but more like analitics tools B - Could be a thinkg but there is no point of Read-Only from DAX and write to DB cluster. beside it is hard to say if it would be cost effective as we are paying per hour not R/W requests as it is with replica. Hence I would go with C
Comment: AnswerAE Amazon Kinesis data firehose for data ingesting, and hence output cannot go to EC2, hence Fargate with ECS.
Comment: A is correct for ingesting data. B or E both choises are serverless but the difference is the lambda maximum execution time is 15 minutes. So the right option is E. A and E
Comment: A-ingesting real-time data E- serverless option ECS+fargate
Comment: Lambda maxed to 15mins
Comment: But through Step Functions it would be possible to divide a long task, lasting more than 15 minutes, into multiple Lambda invocations with a maximum duration of 15 minutes.
Comment: The maximum run time for lambda is 15 mins.
Comment: AnswerA
Comment: no internet, S3 > gateway VPC endpoint
Comment: VPC endpoint
Comment: "data cannot be sent over the public internet." == VPC Endpoint
Comment: Option A
Comment: Since need analyze the current EBS volume cost and to recommend optimizations, so have to use AWS compute optimizer
Comment: AnswerD AWS Compute Optimizer helps avoid overprovisioning and underprovisioning four types of AWS resources—Amazon Elastic Compute Cloud (EC2) instance types, Amazon Elastic Block Store (EBS) volumes, Amazon Elastic Container Service (ECS) services on AWS Fargate, and AWS Lambda functions—based on your utilization data. https://aws.amazon.com/compute-optimizer/
Comment: Get recommendations to optimize your use of AWS resources
Comment: AWS Compute Optimizer helps avoid overprovisioning and underprovisioning four types of AWS resources—Amazon Elastic Compute Cloud (EC2) instance types, Amazon Elastic Block Store (EBS) volumes, Amazon Elastic Container Service (ECS) services on AWS Fargate, and AWS Lambda functions—based on your utilization data.
Comment: https://aws.amazon.com/blogs/aws/s3-storage-lens/
Comment: Correct answer: A A: You can use an AWS Config managed rule to identify Amazon S3 buckets that do not have versioning enabled.
Comment: Question #889 contains all the answers including A, which is cloudtrail and obviously wrong. On the other hand S3 Storage Lens: You can use the Versioning-enabled bucket count metric to see which buckets use S3 Versioning. Then, you can take action in the S3 console to enable S3 Versioning for other buckets. So correct answer: B
Comment: Where is option A
Comment: where is option A?
Comment: "Standard queues support at-least-once message delivery, and FIFO queues support exactly-once message processing and high-throughput mode." https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html#sqs-benefits
Comment: must process each order exactly once -> FIFO queue
Comment: AnswerA SQS with FIFO queue will allow to read every customer order in order in which they came and only once.
Comment: FIFO queue is the solution
Comment: SQS and FIFO
Comment: FIFO > SQS
Comment: The application must process each order exactly once == SQS + FIFO
Comment: answer should be D
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
Comment: Weird question, but D is actually the only one that allow you to select which developer got access and when, so will go for D
Comment: Agree, as C will let any developers assume the role without control
Comment: I check here: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html, and yes it should be use IAM role, I correct my choice to C
Comment: you can't assign groups as principals, b and c don't specify only the senior devs, a is the only one that works here
Comment: edit, none of these answers are right....
Comment: If you want ALL the developers to assume the role in the production, then C using a trust policy to assume the role in production is perfect BUT You could allow users in development account to assume the role in production, but in the end you will maintain potentially a big trust policy depending of the total number of users. Here you want only some developers to connect to the production (others will follow without knowing if they all can connect and without knowing the number) so managing a separate group will give you a little more maintenance but will allow you to have different rights between the users. I'd say D
Comment: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
Comment: i think D is better
Comment: Authen: Cognito Globally: Lambda@Edge + cloudfront
Comment: Serve content globally means the use of Cloudfront
Comment: Implementación a nivel global ==> AWS Cloud Front
Comment: why is it not A? If the goal is only to prevent launch of EC2s
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Comment: Inspector for Common vulnerabilities so it is B
Comment: AWS Security Hub performs security best practice checks, aggregates alerts, and enables automated remediation. Amazon Inspector scan workload for vulnerabilities Guardduty threat detection for malicious activity in all account AWS Shield DDOS Regarding security B and D can be right (maybe D a little too much). For patching B is the only valid option.
Comment: inspector for instances and software vulnerabilities
Comment: AWS Systems Manager Patch Manager to automate the process of installing security-related updates for both the operating system and applications. Amazon Inspector for Automated and continual vulnerability management at scale
Comment: Create an Auto Scaling group and an ELB in the DR Region, configuring the DynamoDB table as a global table, and setting up DNS failover to the new ELB. This approach allows for quick failover since the infrastructure is already in place and only DNS needs to be updated to redirect traffic.
Comment: Inspector for vulnerability scanning
Comment: Option b
Comment: Downtime I would choose Auto scaling + DNS failover rather than use cloud formation create infrastructure in DR region or Auto scaling + Lambda
Comment: Downtime I would choose Auto scaling + DNS failover rather than use cloud formation create infrastructure in DR region or Auto scaling + Lambda
Comment: AnswerA Hence there is no information that solution need to be cost effective and the main requirement is minimal downtime i would go with AUTOSCALING in DR region with 1 ELB and 1 server there but in case of need amount of servers can be increased automatically. Hence at least 1 server and ELB will be waiting and DynamoDB thanks to global table will be active in the same DR region as well, hence we need to inform users, using DNS about new destination, hence DNS failover to the ELB in DR region is the best solution here.
Comment: With dynamo global tables, we just need to create an ELB and a ASG in the DR region resources. This resources will be used only if the main region fail over.
Comment: Create an Auto Scaling group and an ELB in the DR Region, configuring the DynamoDB table as a global table, and setting up DNS failover to the new ELB. This approach allows for quick failover since the infrastructure is already in place and only DNS needs to be updated to redirect traffic.
Comment: Least downtime. C does not offer minimal downtime
Comment: Option C
Comment: Gateway endpoint free, so definitely interface end point expensive than it
Comment: AnswerD https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html taking into consideration that in both cases (s3 Instance Endpoint and S3Gateway endpoint), network traffic remains on the AWS network we need to think about other data which we have. For example application is in AWS cloud hence there is no need for access from on-premises. in that situation S3 Gateway endpoint seems to be better (and it is for free) https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3
Comment: D for sure.
Comment: Gateway endpoints are free.
Comment: Sorry, I think D is the correct option. Gateway endpoint is cheaper than Interface endpoint
Comment: Gateway endpoint for S3
Comment: should be C
Comment: Answer is A & D - By deploying EC2 instances in multiple Availability Zones (Option A), you ensure that your application remains available even if one Availability Zone experiences an outage. This setup provides redundancy and fault tolerance.
Comment: as it mention "The application is accessible by using the transport layer" which is TCP, so no more information or reason to use ALB as well, so I will go for B+D
Comment: as it mention "The application is accessible by using the transport layer" which is TCP, so no more information or reason to use ALB as well, so I will go for B+D
Comment: AnswerBD There is no information about the ports numbers and only that means that we need to use NLB, ALB is only for HTTP hence there is no point of using that solution as connection can be done via any port for exampl 4000 Autoscaling with instances in multiple AZ is the best solution. it will allow run new EC2 if it fail and in case if whole AZ will go down we will have 2nd one.
Comment: No word about the HTTP/application layer, only OSI 4 - TCP > B, an NLB should be enough D: for Autoscaling.
Comment: transport layer means just NLB.
Comment: B- since network layer operates at layer 4 i.e transport layer D- for hHA
Comment: Edited-D option for HA
Comment: question says the application is running on Transport Layer. i dont think there is need for ALB
Comment: as it said "The company expects fewer than 100 site visits each month" and Lambda charge per each time calling it, so i will go for B
Comment: Limitation is 100 submission a month, not frequent -> Lambda
Comment: AnswerB API gateway + Lambda seems to be the best option expecially when SNS is in use which is specially created to push messaged to the subscribers (company appropraiate team in this situation)
Comment: B is the right answer
Comment: D is correct answer. Configuring each AWS account's root user to use email aliases that go to a centralized mailbox ensures that sensitive notifications are not directly sent to individual email addresses. Instead, they are directed to a centralized mailbox, reducing the risk of unauthorized access to sensitive information. Additionally, configuring alternate contacts for each account using a single business-managed email distribution list for the billing team, the security team, and the operations team ensures that notifications are appropriately routed to the respective teams based on the categories of billing, operations, or security. This approach centralizes control and reduces the likelihood of misconfiguration or unauthorized access to sensitive notifications.
Comment: Option A doesn't provide the same level of security because it relies on a single email address managed by the company, which could be compromised, and it requires all account owners to access this email account, potentially leading to access control issues. Option B presents a similar issue as Option A, as it relies on different email distribution lists but still requires administrator email addresses that may be vulnerable to compromise. Option C also has security concerns because it associates the root user email address with individual employees, which may not be ideal for security and access control purposes. So, Option D is the most secure solution for ensuring that future notifications can be sent to different employees based on the notification categories of billing, operations, or security.
Comment: Both B and D use Distribution Lists as part of the of the solution: B - "configure each DL with administrator email addresses that can respond to alerts" D - "configure alternate contacts for each account by using single business managed DL each" per team. I confess the wording isn't amazing, but between B and D, the latter is the one that properly addresses the issue involving root user email address.
Comment: correct answer is D
Comment: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html
Comment: Question mentions the email was sent to a business unit account instead of an account owner. Thus, A mentions all account owners to have access to email account.
Comment: A) uses RDS Proxy which is mainly for connection pooling and availability issues. Proxy is for too many connections(, not for performance: read replicas, caching) B is caching which is designed for solving read-issues. (Here we have timeouts, and connection issues.) C: SQS is good method for decoupling.
Comment: i think it's BC
Comment: BC. Not idea why retry helps in this scenario besides it adds more complexity into the current design and also doesn't resolve the avalibility issue...
Comment: B and C!
Comment: A - simply pointless. B- You're already using SQS (C), so why using ec2 to "retry the purchase"? They will stay in the queue until the purchase is processed. Otherwise, they will simply return to the queue. C - This decouples the application from direct database calls, allowing the processing of purchase requests to scale independently and manage load more effectively.
Comment: when we have SQS in option C why do you have to retry it again I think the answer is B and C
Comment: Combine SQS and auto-scaling EC2: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
Comment: QuickSight for dashboard and Athena for query each month so it is B
Comment: Senior Leadership, custom dashboard, visualization: Quicksight Dashboard S3 query: Athena
Comment: B. Share an Amazon QuickSight dashboard that includes the requested table visual. Configure QuickSight to use Amazon Athena to query the new report. QuickSight works well with Athena and it can interact S3
Comment: You definitely use Athena to request S3. Both cloudwatch and quicksight can interact with S3. Since we are taking about "The company's senior leadership" I'd tend to use quicksight for a better format.
Comment: You simply can't have A and E in the same approach: "Default TTL applies only when your origin does not add HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires to objects." C - Cache-Control private directive specifies that the response is intended for a single user and should not be cached by shared caches - it can still be cached, but only on a client device. This combination of steps would provide the best solution for the case. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesDefaultTTL
Comment: A-C, Because A-E is not possible following this link: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesDefaultTTL "Default TTL applies only when your origin does not add HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires to objects."
Comment: If the content still keep client's cache in 24h, its wrong (answer E)
Comment: If your minimum TTL is greater than 0, CloudFront uses the cache policy's minimum TTL, even if the Cache-Control: no-cache, no-store, and/or private directives are present in the origin headers. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
Comment: "However, the company also wants to ensure that stale content is not served for more than a few minutes after a deployment." After a deployment
Comment: Answer (AC) Per table on URL https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#expiration-individual-objects answer E is incorrect because if we will change cache-control max-age to 24h it will means that customer browser will cache web for 24h and customer want to be sure that it will be not longer then few min. Expires header (answer D) from my understanding can be used only on full folder of web not as lambda function which will reply to customer reqeusts. We are setting Default TTL for CloudFront (answer A) not on S3 (answer B) and it will say CloudFront to cache web for 2min.
Comment: Adding Cache-control private (answerC) will work per customer wish but only if we will add them to the objects which are changed very often or if we will set minimum TTL. In the 1 situation User Browser will not store files which we designate to be often changed and mentioned files will be downloaded every time from origin. In the 2 situation, Cloud front will cache web files for min TTL time but customer browser will not store them. Taking all that in to account I would go with AC
Comment: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#expiration-individual-objects https://stackoverflow.com/questions/43343759/confused-with-minimum-maximum-and-default-ttl-in-cloudfront
Comment: Since it don't want to cache more than a minute, A cannot be an answer
Comment: Answer is AE , C would only be on the user browser and would not cache to the cloud front and would be useless
Comment: AE. By default, each file automatically expires after 24 hours, but you can change the default behavior in two ways: 1. To change the cache duration for all files that match the same path pattern, you can change the CloudFront settings for Minimum TTL, Maximum TTL, and Default TTL for a cache behavior. 2. To change the cache duration for an individual file, you can configure your origin to add a Cache-Control header with the max-age or s-maxage directive, or an Expires header to the file. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#expiration-individual-objects
Comment: Add a Cache-Control Private Directive to Objects in Amazon S3 (Option C): By setting the Cache-Control header to private for objects in the S3 bucket, you control caching behavior. The private directive indicates that the content is intended for a single user and should not be cached by intermediate proxies or CDNs. This helps prevent stale content from being served to multiple users. Additionally, consider using other Cache-Control directives (e.g., max-age, no-cache, no-store) as needed.
Comment: Compute Savings Plan: This plan offers significant discounts on Lambda functions compared to on-demand pricing. Since the application will run for a year, a sustained use discount like Compute Savings Plan is ideal. Private Subnets: Lambda functions in private subnets can directly access EC2 instances within the VPC without needing internet access, reducing security risks and potential egress costs.
Comment: Compute savings include lamdba and EC2, Ec2 savings only EC2 instances. https://aws.amazon.com/savingsplans/compute-pricing/
Comment: I confuse this Question. Instance saving plan is cheaper than compute saving plan. https://aws.amazon.com/savingsplans/compute-pricing/
Comment: But composite saving plan discount Automatically applies to Lambda.
Comment: Sorry I mean Compute Savings Plan.
Comment: In this question has point out "access EC2 instances" within VPC,=> Lambda VPC to an ENI (Elastic network interface) in your account VPC.=>No charge. Therefore I stick with A, Not D.
Comment: An EC2 Instance Savings Plan is limited to savings on EC2 instances only. It does not provide cost savings for Lambda functions. Therefore, it is not the best choice given that the number of Lambda functions is expected to increase.
Comment: I am sorry I mean C
Comment: AnswerD https://docs.aws.amazon.com/lambda/latest/dg/foundation-networking.html
Comment: As beautifully explained in this article: https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html
Comment: (A) is eliminated. 'send a daily report to each developer' can be ignored. (C) is eliminated. 'detect anomalous spending' won't stop the spending. (D) is eliminated. 'stop running resources at the end of each work day' won't stop developers from mining bitcoin ($$$) the next day. (B) is correct. 'actions to apply a DenyAll policy..' is the only solution that will 'implement controls to limit AWS resource costs that the developers incur.'
Comment: I'd definitely be mining bitcoin the next day...
Comment: AnswerB https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html Taking into consideration that AWS Budgets is allowing to will inform you that you exceeded budged and execute actions like for example IAM actions to prevent running new resources in cloud, I think this option is a good and resonable move. In case of need budged can be always increased and "chains" disabled.
Comment: Seem AWS Budgets does not have DenyAll function but only Apply a custom Deny IAM policy that restricts the ability for a user, group, or role to provision additional Amazon EC2 resources
Comment: B and D are too aggressive. A - "Instruct each developer", nope, too much operational work.
Comment: My first instinct says B, but Im concerned about the central management abilities of AWS Budgets. It seems that even though it is not planned to be used primarily to control other accounts its still possible: "You can use actions to define an explicit response that you want to take when a budget exceeds its action threshold. You can trigger these alerts on actual or forecasted cost and usage budgets. 1. The management account sets the budget and threshold for the member account using budget filters. 2. When the budget threshold is breached, a budget action applies a restrictive SCP on the OU. So hopefully B :D
Comment: Security group is stateful, just need allow Inbound.
Comment: Agree since security group is stateful so allow inbound is enough
Comment: AnswerACE: Security Group is protecting instances, it's statefull. by defoult is allowing for outgoing traffic but not incomming. hence we need to allow for inboud traffic. path looks like below ALB >>HTTPS>> WEB tier >>HTTPS>> Application >>SQL traffic>> SQL DB hence we need allow for incoming https traffic on web tier then incomming http on app tier and on the end for incomming sql traffic on DB tier
Comment: ALB >>HTTPS>> WEB tier >>HTTPS>> Application >>SQL traffic>> SQL DB
Comment: It's pretty obvious, although it's called: Machine Learning Savings Plans for Amazon SageMaker (C) For the compute workloads we need a compute savings plan, that covers all the 3 compute options we use here (EC2, Lambda and Fargate) (D)
Comment: no doubt
Comment: Answer CD https://aws.amazon.com/savingsplans/ml-pricing/ https://aws.amazon.com/savingsplans/compute-pricing/
Comment: DMS + SCT is correct, but " rewrite the SQL queries in the applications." is wrong so A + E are out. Then only left B + C -> DMS + SCT + Babekfish (for SQL Server)
Comment: AnswerBC DMS will allow for DATABASE migration and use AWS Schema Conversion Tool (AWS SCT) to create some or all of the target tables, indexes, views, triggers, and so on. https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html To minimalize amount of code which need to me changes we need to use babelfish https://aws.amazon.com/rds/aurora/babelfish/
Comment: https://aws.amazon.com/rds/aurora/babelfish/
Comment: B: Babelfish for Aurora PostgreSQL is a new capability for Amazon Aurora PostgreSQL-Compatible Edition that enables Aurora to understand commands from applications written for Microsoft SQL Server. C: Is just obvious: Use Data Migration Tool for the migration, Schema Conversion tool for the Schema conversion.
Comment: https://aws.amazon.com/rds/aurora/babelfish/
Comment: AnswerA The task is to force automatic encryption for every new EBS volume and prevent possibility of creation any unencrypted volume hence: https://docs.aws.amazon.com/ebs/latest/userguide/work-with-ebs-encr.html#ebs-encryption_key_mgmt To enable encryption by default for a Region Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. From the navigation bar, select the Region. From the navigation pane, select EC2 Dashboard. In the upper-right corner of the page, choose Account Attributes, Data protection and security. Choose Manage. Select Enable. You keep the AWS managed key with the alias alias/aws/ebs created on your behalf as the default encryption key, or choose a symmetric customer managed encryption key. Choose Update EBS encryption.
Comment: "The solution must also prevent the creation of unencrypted EBS volumes." For prevention future actions, I go for AWS config. You can setup Encryption in EC2, but Its manual process, what happen if you add one or more EC2?
Comment: AnswerA https://docs.aws.amazon.com/ebs/latest/userguide/work-with-ebs-encr.html#ebs-encryption_key_mgmt To enable encryption by default for a Region Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. From the navigation bar, select the Region. From the navigation pane, select EC2 Dashboard. In the upper-right corner of the page, choose Account Attributes, Data protection and security. Choose Manage. Select Enable. You keep the AWS managed key with the alias alias/aws/ebs created on your behalf as the default encryption key, or choose a symmetric customer managed encryption key. Choose Update EBS encryption.
Comment: A. https://repost.aws/knowledge-center/ebs-automatic-encryption
Comment: As it needs to prevent creation of Unencrypted EBS volume
Comment: B es correcto , AWS Config para identificar automáticamente los volúmenes de EBS no cifrados y aplicar una acción correctiva.A,C,D : incorrectas , no cumplen con el cifrado automático
Comment: B - C are out = Glue doesn't support real-time data processing. D - Why would you use Kinesis data ANALYTICS to ingest clickstream data instead of Amazon Kinesis DATA STREAM?
Comment: This one is very tricky, need to read the context carefully: "The company needs a scalable solution that can adapt to varying levels of traffic" -> Both Firehouse and Stream are scalable. But, Firehose is automatic where Stream is not. However, the question does NOT say it should be automatic and Glue is not support real-time analysis. Thats why go for A. B is very close to.
Comment: AnswerA Apache Flink (previously known as Amazon Kinesis Data Analytics) seems to not allowing sent data directly to Lambda... Glue is allowing to integrate data from couple of sources in to one. Hence I think A is correct answer https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html https://aws.amazon.com/kinesis/data-streams/features/?nc=sn&loc=2
Comment: Seem AWS Glue does not support process data in real time. I vote for A
Comment: Both Kinesis Data Streams and Firehose are scalable but Firehose offers automated scaling. I vote fore B
Comment: I think Apache Flink (previously known as Amazon Kinesis Data Analytics) would also be fine, but as here it wants to combine it with Lambda, I would rather opt for Kinesis Data Streams + Lambda, so A, because of the figure on this page: https://aws.amazon.com/kinesis/
Comment: AnswerB S3 Sorage Lens "can also identify buckets that aren't following data-protection best practices, such as using S3 Replication or S3 Versioning. " https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html
Comment: You can use the Versioning-enabled bucket count metric to see which buckets use S3 Versioning. Then, you can take action in the S3 console to enable S3 Versioning for other buckets.
Comment: Although it's not stated what is meant by 'rarely accessed', this scenario would primarily be a candidate for the Glacier Instant Retrieval tier as the storage price would be more than 3 times lower compared to Standard IA. In the specific case of files being more frequently retrieved than quarterly, it can qualify for consideration of Standard IA. Actually, we don't have the required info, so we have to guess what they are thinking.. which is pretty lame, to be honest..
Comment: S3 Glacier Instant Retrieval only retain the file for maximun 90 days, that is why A is not correct answer. So C is right answer.
Comment: Hell no. S3 Glacier Instant Retrieval is designed for long-lived, rarely accessed data that is retained for months or years. Objects that are archived to S3 Glacier Instant Retrieval have a minimum of 90 days of storage
Comment: No, it isn't. It is just the opposite. Objects archived to S3 Glacier Flexible Retrieval have a minimum of 90 days of storage. If an object is deleted, overwritten, or transitioned before 90 days, a pro-rated charge equal to the storage charge for the remaining days will be incurred. https://aws.amazon.com/s3/faqs/?nc=sn&loc=7
Comment: Instant Retrieval = immediately accessible. Coose the S3 Glacier Instant Retrieval storage class when you need milliseconds access to low cost archive data. https://aws.amazon.com/s3/faqs/?nc=sn&loc=7
Comment: Glacier Instant Retrieval is much cheaper, and it is intended for archival storage with very low access patterns
Comment: While S3 Glacier Instant Retrieval offers immediate access, it has a minimum storage duration policy, Objects stored in S3 Glacier Instant Retrieval have a minimum storage duration of 90 days.
Comment: S3 Glacier Instant Retrieval delivers the fastest access to archive storage, with the same throughput and milliseconds access as the S3 Standard and S3 Standard-IA storage classes. --- https://aws.amazon.com/s3/storage-classes/glacier/instant-retrieval/
Comment: cost effective -> OneZone IA "The files must be immediately accessible" -> cannot be Glacier
Comment: Instant Retrieval = immediately accessible. Coose the S3 Glacier Instant Retrieval storage class when you need milliseconds access to low cost archive data. https://aws.amazon.com/s3/faqs/?nc=sn&loc=7
Comment: files can not be recreated -> OneZone IA not accepted
Comment: this option has most durability
Comment: "are rarely accessed after the first 30 days" - not often I will go with "C".
Comment: https://aws.amazon.com/es/s3/storage-classes/glacier/instant-retrieval/
Comment: mmediately accessible =>C
Comment: AnswerC We cannot choose B because if that one zone will fail, company will not be able to recreate them. We cannot choose D because we do not have to store files after 4y hence we can delete them (cost savings) We cannot choose A - Glacier is less expensive (0,004 per GB) then S3-Standard - IA but is not allowing for instant access which is one of requirements (there is no information that data access shouldn't be accessible immedietly) we have only information that after 30d access to data is less frequently. Hence I think we need to choose S3 Standard - IA (answer C)
Comment: Requirements: - frequently accessed for 30 days - lower cost Features for S3 Standard-IA: - Infrequently accessed objects - Milliseconds to acces According to me, best option for this use case is C NB: Glacier better suits for lower cost, infrequent access.
Comment: why do we need one zone, glacier instant for 30 days ? or why do we need to move to glacier after 4 years ? I think C is correct
Comment: B. Create an S3 Lifecycle policy to move the files to S3 One Zone-Infrequent Access (S3 One Zone-IA) 30 days after object creation. Delete the files 4 years after object creation. This option leverages S3 One Zone-IA, which offers a lower cost compared to S3 Standard-IA, while ensuring that files are immediately accessible during the first 30 days of their creation. Then, after this period, the files are moved to S3 One Zone-IA for less frequent access storage, further reducing costs. Finally, the files are deleted after 4 years, meeting the requirement for long-term retention.
Comment: Using a Multi-region Accesspoint in an Active-Active setup will send data to the closest Region, without accessing the internet: "send remote user data to the nearest S3 bucket with no public network congestion" Not very easy to read and understand but it's all there: https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html
Comment: D. Set up Amazon S3 to use Multi-Region Access Points in an active-active configuration with a single global endpoint. Configure S3 Cross-Region Replication.
Comment: D is correct
Comment: Answer D https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html When you create a Multi-Region Access Point, you specify a set of AWS Regions where you want to store data to be served through that Multi-Region Access Point. You can use S3 Cross-Region Replication (CRR) to synchronize data among buckets in those Regions. You can then request or write data through the Multi-Region Access Point global endpoint. Amazon S3 automatically serves requests to the replicated dataset from the closest available Region. Multi-Region Access Points are also compatible with applications that are running in Amazon virtual private clouds (VPCs), including those that are using AWS PrivateLink for Amazon S3. https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
Comment: To me it looks like C, the requirement is to send the request to the closest region
Comment: It's D. In an active-active configuration, requests made to an S3 Multi-Region Access Point's global endpoint automatically route over the AWS global network to the nearest S3 bucket. This allows applications to automatically avoid congested network segments on the public internet, improving application performance and reliability.
Comment: NOT A: Autoscaling with Maximum of 1 EC2 :D NOT B: Hourly backup... RPO 1hr C: AMI, Multi-AZ -> Fault tolerant NOT D: ECS with Fargate, but it needs to run on EC2..
Comment: You cannot change application and based on the story in the past there was only one server/copy of application running at the same time. So we cannot run more then one copy of any application at once. It is possible to set Min and Max to 1 which will automatically bring up server when it will crash. Taking into consideration that we cannot change application design and load-balancing between regions would probably need that (no information if applications are statefull or stateless) i would go for solution in answer A
Comment: Autoscaling with max=1 is what is needed to keep only one instance at a time - it will still fail, but it will spawn exactly one instance in case of failure (we are not allowed to change the design of the app) Having single instances in different AZ will not help - if one of the AZs is down, the app will still be affected
Comment: I don't see how people can choose A here when it is talking about reliability and the answer only has a maximum of 1. There's nothing about cost effectiveness so there is no reason this one is better. Definitely C.
Comment: A. Create an Auto Scaling group that has a minimum of one and a maximum of one. Create an Amazon Machine Image (AMI) of each application instance. Use the AMI to create EC2 instances in the Auto Scaling group Configure an Application Load Balancer in front of the Auto Scaling group.
Comment: Fault tolerance is not High Availability Answer A is HA design, not Fault tolerance
Comment: A makes sense. C is possible but manual intervention.
Comment: answer is A. Auto Scaling Group: Explanation: Minimum and Maximum of one instance: Ensures that the instance is always running. If the instance fails, Auto Scaling will automatically replace it with a new one, maintaining high availability. Amazon Machine Image (AMI): Captures the current state of the application instance, ensuring that new instances launched by Auto Scaling will have the same configuration. Application Load Balancer (ALB): Load Balancer: Distributes traffic to the instances in the Auto Scaling group, ensuring fault tolerance. Even though there is only one instance, the ALB can help manage incoming traffic and be ready for future scaling if needed. For C: While this provides high availability, it does not address fault tolerance as effectively as the Auto Scaling group approach. Without Auto Scaling, if an instance fails, manual intervention is required to launch new instances.
Comment: A makes sense
Comment: It's either A or B but A is a better option. The application design cannot be changed so we don't know if it can run across 2 servers.
Comment: Answer A It is possible to set Min and Max to 1 which will automatically bring up server when it will crash. Taking into consideration that we cannot change application design and load-balancing between regions would probably need that (no information if applications are statefull or stateless) i would go for solution in answer A https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html
Comment: Statement: - The solution also must create accounts with automatic security controls (guardrails). https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html AWS Control Tower provides a pre-packaged set of guardrails (policies) and blueprints (best-practice configurations) to ensure that the environment complies with security and compliance standards. It's designed to simplify the process of creating and managing a multi-account AWS environment while maintaining security and compliance.
Comment: It's a hard one. I'd go for B Several accounts in an org, with central mgmt > AWS Organization Sharing resources among accounts > AWS RAM AWS Organizations and RAM typically work well together... Happy to be challenged, of course.
Comment: Although automatic security control could be a hint for AWS Control Tower (set up and operate your multi-account AWS environment with prescriptive controls)
Comment: A Guardrails >> AWS Control Tower
Comment: AWS Control Tower provides built-in guardrails and automates the creation of accounts with security controls.
Comment: A. Use AWS Control Tower to deploy accounts. Create a networking account that has a VPC with private subnets and public subnets. Use AWS Resource Access Manager (AWS RAM) to share the subnets with the workload accounts.
Comment: It leverages AWS Control Tower for automated account deployment and management, along with AWS RAM for centralized networking management, thus minimizing operational overhead while meeting the company's requirements for workload isolation and automatic security controls.
Comment: answer is A
Comment: Anser is A, Control Tower has guardrails AWS Audit Manager provides an AWS Control Tower Guardrails framework to assist you with your audit preparation.
Comment: Taking into consideration that AWS Control Tower is Orchestrator for AWS Organization which applies guardrails, I think A is a good choose. https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
Comment: Please explain why the answer is option A
Comment: I prefer B which is free. A may cause fee for sevice used while I am not sure about it.
Comment: Answer A Based on https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html Amazon CloudFront: Uses the durable storage of Amazon Simple Storage Service (Amazon S3) – This solution creates an Amazon S3 bucket to host your static website's content. To update your website, just upload your new files to the S3 bucket.
Comment: website serves static content So we need to ElastiCache when traffic increases , no need for cloudfront
Comment: A. Move the website to an Amazon S3 bucket. Configure an Amazon CloudFront distribution for the S3 bucket.
Comment: S3 for static contents, and ElastiCache for traffic increasing. No need for cloudfront cuz there is no need for global deliver for the website
Comment: " customers often complement S3 with an in-memory cache, such as Amazon ElastiCache for Redis, to reduce the S3 retrieval cost and to improve performance." --https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/
Comment: static content -> S3
Comment: D. Create an Amazon FSx for Windows File Server file system. Connect the application server to the file system.
Comment: Answer D https://aws.amazon.com/fsx/windows/
Comment: SMB protocol -> FSx windows
Comment: B. Convert the Aurora cluster to an Aurora global database. Configure managed failover.
Comment: I go for B. However, C is also a good option except manual failover intervention
Comment: Answer:B https://aws.amazon.com/rds/aurora/global-database/ Cross-Region disaster recovery If your primary Region suffers a performance degradation or outage, you can promote one of the secondary Regions to take read/write responsibilities. An Aurora cluster can recover in less than 1 minute, even in the event of a complete Regional outage. This provides your application with an effective recovery point objective (RPO) of 1 second and a recovery time objective (RTO) of less than 1 minute, providing a strong foundation for a global business continuity plan.
Comment: Aurora Global Database: allowing a single Amazon Aurora database to span multiple AWS Regions. It replicates your data with no impact on database performance, enables fast local reads with low latency in each Region, and provides disaster recovery from Region-wide outages.
Comment: B is wrong because the job takes 1 hour and the lambda maximum execution time is 15 minutes. C is wrong can't use spot instances because the job can not tolerate interruptions. D iswrong too because DataSync is not designed to lunch jobs. Correct answer is A
Comment: I know datasync and lambda is event based, there are interruptions. C, doesnt address the scheduling requirement. Has to be A
Comment: A. Create a container for the job. Schedule the job to run as an AWS Fargate task on an Amazon Elastic Container Service (Amazon ECS) cluster by using Amazon EventBridge Scheduler.
Comment: Answer: A Fargate is compatibilie with ECS and is allowing for log running tasks
Comment: A, B, D are senseless + Amazon Security Lake automatically centralizes security data from AWS environments, you can get a more complete understanding of your security data across your entire organization. You can also improve the protection.
Comment: C. Configure a data lake in Amazon Security Lake to collect the security data. Upload the data to an Amazon S3 bucket.
Comment: Answer C https://aws.amazon.com/security-lake/ Amazon Security Lake automatically centralizes security data from AWS environments, SaaS providers, on premises, and cloud sources into a purpose-built data lake stored in your account.
Comment: D. Deploy a transit gateway with associations between the transit gateway and the application VPCs and the shared services VPC. Add routes between the application VPCs in their subnets and the application VPCs to the shared services VPC through the transit gateway.
Comment: AWS Transit Gateway: Centralized Connectivity: AWS Transit Gateway provides a hub-and-spoke model for connecting multiple VPCs, simplifying network management by providing a single point of connectivity for all VPCs. Scalability: It is designed to handle many VPCs, making it suitable for scaling beyond the initial five applications to more than 100 applications. Reduced Administrative Overhead: Managing VPC peering connections or VPN tunnels for each pair of VPCs would become complex and difficult to manage at scale. Transit Gateway simplifies this by providing centralized routing and connectivity.
Comment: the LEAST administrative overhead = transit gateway
Comment: Answer: D https://aws.amazon.com/transit-gateway/ Looks like the best solution would be transit gateway. It will allow for inter-VPC communication for all 5 applications/VPC, reach shared resource/VPC and in the future it will be easy to allow for inter-communication between even 100 VPCs (applications)
Comment: D. https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html
Comment: Correct answer is B
Comment: AB.the combination of setting up an ECS cluster with Fargate for the cloud and ECS Anywhere for on-premises, along with using an Application Load Balancer, provides a scalable, hybrid, and cloud-native solution with minimal operational overhead.
Comment: the combination of setting up an ECS cluster with Fargate for the cloud and ECS Anywhere for on-premises, along with using an Application Load Balancer, provides a scalable, hybrid, and cloud-native solution with minimal operational overhead.
Comment: Have to use fargate, and since it has on-premises application so it need to use Amazon ECS Anywhere
Comment: Answer: AB We need to load-balance HTTP traffic hence Application Load Balancer is needed. Because Customer want to use container solution we need to use ECS with Fargate which will lunch cloud applications. To run on-premises applications in containers we need to use ECS Anyware. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html
Comment: Amazon ECS services on AWS Fargate support the Application Load Balancer and Network Load Balancer load balancer types. Application Load Balancers are used to route HTTP/HTTPS (or layer 7) traffic. Serverless (AWS Fargate (Fargate)) in the AWS cloud Fargate is a serverless, pay-as-you-go compute engine. With Fargate you don't need to manage servers, handle capacity planning, or isolate container workloads for security. On-premises virtual machines (VM) or servers Amazon ECS Anywhere provides support for registering an external instance such as an on-premises server or virtual machine (VM), to your Amazon ECS cluster.
Comment: BD. https://aws.amazon.com/blogs/aws/getting-started-with-amazon-ecs-anywhere-now-generally-available/
Comment: AB is the correct answer,must lunch the cluster as external lunch
Comment: Migrate the databases to a Multi-AZ Amazon RDS for SQL Server DB instance. Use an AWS Key Management Service (AWS KMS) AWS managed key for encryption.
Comment: B. Migrate the databases to a Multi-AZ Amazon RDS for SQL Server DB instance. Use an AWS Key Management Service (AWS KMS) AWS managed key for encryption.
Comment: B. Migrate the databases to a Multi-AZ Amazon RDS for SQL Server DB instance. Use an AWS Key Management Service (AWS KMS) AWS managed key for encryption. This option provides the best balance between increased security, reduced operational overhead, and maintaining the relational database functionalities that the company needs.
Comment: A. Create an Auto Scaling group that contains multiple Amazon EC2 instances that host the application across two Availability Zones. Configure an Application Load Balancer (ALB) and set the Auto Scaling group as the target. Connect a WAF to the ALB.
Comment: AnswerA WAF > ALB > AutoScalingGroup(MultiAZ EC2 Instances) Looks good
Comment: A: EC2 - MultiAZ > ALB > WAF
Comment: Not D because AWS WAF cannot be directly connected to an Auto Scaling Group, it should be associated with the ALB which managing the incoming web traffic
Comment: A. Create dedicated S3 access points and access point policies for each application.
Comment: Explanation: S3 Access Points: These provide a way to manage access to shared data sets in Amazon S3. Each access point has a unique hostname and a policy that is specific to the use case, allowing for granular control over access to data. Access Point Policies: These policies can be tailored to restrict access to specific prefixes within an S3 bucket, ensuring that each application only has access to its designated prefix.
Comment: Answer A By creating separate access points for each application, you can enforce access controls specific to their respective prefixes while minimizing administrative complexity. This approach provides a clean separation of permissions and reduces the risk of misconfigurations. Options B, C, and D are not as efficient or straightforward: Option B (S3 Batch Operations) involves setting ACL permissions for each object individually, which can be cumbersome and time-consuming. Option C (replicating objects to new S3 buckets) introduces additional buckets and replication rules, increasing management overhead. Option D (replicating objects and creating dedicated S3 access points) adds unnecessary complexity by combining replication and access point creation.
Comment: Answer B Taking into consideration that we have "numerous applications" (10,100,1000?) and we need meet requirements with the LEAST operational overhead I would go into authomatization of operations hence Batch Operations seems to be good choice. https://aws.amazon.com/blogs/storage/updating-amazon-s3-object-acls-at-scale-with-s3-batch-operations/
Comment: However, answer B need to set ACL for each OBJECT inside each S3... and the Batch operation has to be executed where there another new object added to the S3. I am not sure the answer too : )
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-policies.html
Comment: Create an S3 Batch Operations job to set the ACL permissions for each object in the S3 bucket
Comment: I have 2 questions: Is a bacth process there to set ACL permissions. Secondly, they are asking with least operational overhead. Isnt A CORRECT?
Comment: Congratulations! Once again, You made it!
Comment: Answer A I would go with Lambda and SQS. when using SQS we will be sure that all images will be processed and hence to process we need 2 min and 512 MB of memory (Lambda is allowing upto 15 min and upto10K MB) Lambda should be perfect scalable solution which will allow for almost in real time image processing.
Comment: and it is cost effective ;)
Comment: Is there anyone who has recently passed the exam who can tell me approximately how many of the original questions are in the actual exam?
Comment: A. Use S3 Event Notifications to write a message with image details to an Amazon Simple Queue Service (Amazon SQS) queue. Configure an AWS Lambda function to read the messages from the queue and to process the images.
Comment: We made it to the last one! Good luck!
Comment: (B) is eliminated. Reserved instances are more expensive than Spot Fleet. (C) is eliminated. Container instance more expensive than Lambda. SQS needed NOT SNS. (D) is eliminated. Elastic Beanstalk is more expensive than Spot Fleet. SQS needed NOT SNS. (A) is correct. It's the most cost effective service & the scope of its capabilities are within the requirements.
Comment: less than 5 minutes -> use lambda
Comment: TCP >> NLB non-http >> accelerator
Comment: TCP >> NLB non-http >> accelerator.
Comment: AD -TCP use NLB FOR non-http use accelerator.
Comment: Provides a safety net against accidental deletions
Comment: C. Snapshot can be recovered if accidently deleted
Comment: C, AWS Recycle Bin allows you to recover resources like EBS snapshots that were accidentally deleted.
Comment: 7 Days retention period will protect snapshots from being accedently perminantly deleted.
Comment: Snapshot can be recovered if accidently deleted
Comment: https://aws.amazon.com/blogs/aws/new-recycle-bin-for-ebs-snapshots/
Comment: C, A presigned URL grants temporary access to an S3 object without making it publicly accessible.
Comment: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
Comment: Thank you for posting this.
Comment: For me C is the right answer
Comment: A use MSM
Comment: Systems Manager Session Manager allows secure, auditable, and controlled access to your EC2 instances without needing to open SSH ports or manage SSH keys, reducing the attack surface. Local IAM user credentials are less secure and harder to manage at scale compared to using IAM Identity Center.
Comment: D. Create a read replica in us-east-1. Configure the reports to be generated from the read replica.
Comment: Read replicas are typically less expensive than setting up a cross-Region replica or activating Multi-AZ deployments. You only pay for the additional read replica, without the overhead costs associated with cross-Region data transfer or maintaining a synchronous standby in Multi-AZ setups.
Comment: Read replicas are typically less expensive than setting up a cross-Region replica or activating Multi-AZ deployments. You only pay for the additional read replica, without the overhead costs associated with cross-Region data transfer or maintaining a synchronous standby in Multi-AZ setups.
Comment: B. Enable detailed monitoring on all EC2 instances. Use Amazon CloudWatch metrics to perform further analysis.
Comment: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html
Comment: Enabling detailed monitoring on EC2 instances provides metrics at a 1-minute granularity, which is well within the required 2-minute granularity for performance analysis.
Comment: Answer is B
Comment: C. Configure an S3 event notification to invoke an AWS Lambda function each time a user uploads a new photo to the application. Configure the Lambda function to generate a thumbnail and to upload the thumbnail to the second S3 bucket.
Comment: C is correct
Comment: Answer is C
Comment: yes D is the right answer
Comment: D sounds right
Comment: Enable S3 Inventory. Create an AWS Lambda function to filter and delete objects. Invoke the Lambda function with S3 Batch Operations to delete objects by using the inventory reports.
Comment: D is correct
Comment: i think D is also right S3 Bucket Policy: Use an S3 bucket policy that grants access to the specific Lambda functions based on their function ARNs. This ensures that only the authorized Lambda functions can retrieve data from the S3 bucket.
Comment: C sounds right
Comment: A, B and D wrong only C is right
Comment: B sounds right
Comment: Answer is B
Comment: Answer is B
Comment: Answer is D
Comment: B is correct sorry
Comment: REDIS • Multi AZ with Auto-Failover • Read Replicas to scale reads and have high availability • Data Durability using AOF persistence • Backup and restore features • Supports Sets and Sorted Sets
Comment: C sounds right
Comment: Amazon ElastiCache for Redis provides in-memory caching which ensures low latency and high throughput, perfect for near real-time access to player reviews and rankings. Redis supports data persistence by snapshotting data to disk (RDB snapshots) and appending changes to a log (AOF), ensuring that the data is not lost even if the application restarts.
Comment: While enabling server-side encryption in S3 can manage encryption, it does not offer the same level of control and auditing as AWS KMS. Managing individual keys manually in S3 would also increase operational overhead.
Comment: D is with less management overhead
Comment: D is more secure
Comment: D sounds right
Comment: it is obvious that D is correct
Comment: hile enabling server-side encryption in S3 can manage encryption, it does not offer the same level of control and auditing as AWS KMS. Managing individual keys manually in S3 would also increase operational overhead.
Comment: D is the correct Answer
Comment: D sounds right
Comment: D is perfect
Comment: Answer is D
Comment: Answer is D
Comment: D simplifies the process by directly using S3 Standard-IA and then transitioning to S3 Glacier Deep Archive, which aligns well with access patterns and cost requirements. Option A sounds right but using an archive tool to group files into large objects adds complexity and operational overhead. This step isn't necessary if you can directly manage the files with S3 lifecycle policies.
Comment: correct answer is A you need 2 separate lifecycle policy
Comment: answer is D. Storing the objects in S3 Glacier Instant Retrieval for the first year is more expensive than S3 Standard-IA for data that is accessed infrequently.
Comment: Wrong, it says 1-2 times in the first year and Amazon states that s3 glacier isn't at retrieval can save up to 68% compared to s3 infrequent access.
Comment: Its A, took some research but A is correct Per Amazon S# glacier page: "Amazon S3 Glacier Instant Retrieval is an archive storage class that delivers the lowest-cost storage for long-lived data that is rarely accessed and requires retrieval in milliseconds. With S3 Glacier Instant Retrieval, you can save up to 68% on storage costs compared to using the S3 Standard-Infrequent Access (S3 Standard-IA) storage class, when your data is accessed once per quarter." After the one year move it to Deep archive.
Comment: D is most cost effective
Comment: ChatGPT agrees with me and selected A
Comment: D simplifies the process by directly using S3 Standard-IA and then transitioning to S3 Glacier Deep Archive, which aligns well with access patterns and cost requirements. Option A sounds right but using an archive tool to group files into large objects adds complexity and operational overhead. This step isn't necessary if you can directly manage the files with S3 lifecycle policies.
Comment: A looks good
Comment: Answer is A
Comment: Answer is B
Comment: Correct Answer is A Glacier Deep Archive - For long term achieving Glacier Instant Retrieval - Availability for once or twice
Comment: A
Comment: Increase the Provisioned IOPS SSD (io1) EBS volume to more than 64,000 IOPS.
Comment: A is correct, The maximum provisioned IOPS for io1 is 64000 and hence you can achieve higher aggregate performance by adding more io1 volumes
Comment: Question ask for cheapest. Http api offers everything the requirements asked for. i.e Lambda function for serverless, event driven.
Comment: HTTP APIs with Lambda. I'm go with D
Comment: rest is cheaper than http
Comment: Quite the opposite: "REST APIs support more features than HTTP APIs, while HTTP APIs are designed with minimal features so that they can be offered at a lower price."
Comment: An HTTP API instead might not be necessary for this use case.
Comment: D is the right answer
Comment: B or D, Will go with B
Comment: Why B, not D?
Comment: This approach addresses both the high CPU utilization on the EC2 instance and the degraded read performance on the RDS instance effectively.
Comment: A sounds right
Comment: A is correct
Comment: Option B incorrectly suggests redirecting all read/write traffic to the replica. RDS read replicas are designed to handle read operations only, not write operations. Writes must still be handled by the primary DB instance
Comment: B is the right answer. IAM Role
Comment: B sounds right
Comment: Answer is B
Comment: Create an AWS Cognito user pool. Grant developers access to AWS resources by using the user pool.
Comment: BE makes more sense to me. Vertical scaling increases cost continuously even when the instance is in low demand. for a long run, the cost would be higher than just scale horizontally. The questions says the 'poor performance at specific times', so we just need to scale up at specific times. Additionally, in order to scale up, we do need AMI and a launch template. Thus, a combination of B & E should be the correct answer
Comment: The answer is A and E. A for adding more CPU (Vertical scaling ) and E for adding more Servers (Horizontal scaling)
Comment: AWS Compute Optimizer analyzes your current EC2 instance usage and recommends the most cost-effective instance type. In this case, the current instance may not have enough CPU capacity, so scaling vertically (upgrading to a larger instance type) could provide immediate relief from the 100% CPU utilization.
Comment: AE would be the right answer
Comment: BE looks good
Comment: Answer is BE
Comment: BE is the right choice
Comment: https://aws.amazon.com/iam/access-analyzer/
Comment: C is correct
Comment: Answer is C
Comment: B is correct
Comment: Answer is B
Comment: B compliance mode - no one can delete
Comment: Except god. lol
Comment: https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-take-advantage-of-rightsizing-recommendation-preferences-in-compute-optimizer/ be available 24 hours a day, 7 days a week must be highly available => D
Comment: This combination leverages the cost benefits of Fargate Spot for burst traffic while ensuring steady performance with regular Fargate instances.
Comment: B is the right answer
Comment: B- for short work use spot
Comment: B is the right choice, the application must be available 24/7
Comment: Tip: DDoS = Shield, SQL injection = WAF
Comment: Answer is D
Comment: D for DDOS shield advance
Comment: Network Load Balancers (NLB) now supports security groups, enabling you to filter the traffic that your NLB accepts and forwards to your application. Using security groups, you can configure rules to help ensure that your NLB only accepts traffic from trusted IP addresses, and centrally enforce access control policies. This improves your application's security posture and simplifies operations
Comment: Answer is D
Comment: B is correct
Comment: Answer is B
Comment: https://aws.amazon.com/about-aws/whats-new/2023/08/network-load-balancer-supports-security-groups/
Comment: my answer
Comment: ChatGPT agrees with me
Comment: A C F is corrcet
Comment: Answer is ADF
Comment: D makes more sense if the company asks to redesign the whole thing to achieve better operational management, performance, cost effective, etc. However, it requires us to provide solution with MINIMUM change... thus A it is I guess.
Comment: "The company does not want to make any code changes." Option D requires a complete re-architecture of the web portal to be hosted on Amazon S3 and API Gateway, which involves significant changes to the existing system. This does not align with the requirement of minimal changes to the current setup.
Comment: because they don't want any change in code so A is correct.
Comment: A ChatGPT agrees with me
Comment: I think D is better choice. Even though A makes sense too, D seems the correct one
Comment: Least effort, webportal is simply an interface: D
Comment: A sounds right
Comment: i think D
Comment: Answer is A
Comment: I thinks it's D
Comment: most reasonable
Comment: Probably A and C https://repost.aws/knowledge-center/sns-with-crossaccount-lambda-subscription
Comment: A and C seem to be the best answer
Comment: No need to complicate stuff, AWS services already exist only permissions are missing. A&C will set up the necessary permissions and subscriptions for cross-account invocation of the Lambda function by the SNS topic.
Comment: A,C correct - While using SQS could be a solution for buffering messages, it introduces additional complexity
Comment: For me AB is contradict , why we invoke lambda function by both SNS and SQS? I think BE is correct answer because question also need solution to analyze data.
Comment: VOTE A,B
Comment: correct answer is AD
Comment: Probably C https://repost.aws/knowledge-center/eks-custom-subnet-for-pod
Comment: C all the way.
Comment: The Amazon VPC Container Network Interface (CNI) plugin is the default network plugin for Amazon EKS. It allows Kubernetes pods to receive IP addresses from a VPC's subnet and enables pods to communicate securely within the VPC as if they were native VPC resources.
Comment: Answer is A
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html
Comment: Amazon FSx for NetApp ONTAP uses Single-AZ and Multi-AZ deployment types. You can choose from four options: Single-AZ 1, Single-AZ 2, Multi-AZ 1, and Multi-AZ 2
Comment: https://aws.amazon.com/fsx/netapp-ontap/
Comment: Answer is A
Comment: https://aws.amazon.com/blogs/storage/enabling-multiprotocol-workloads-with-amazon-fsx-for-netapp-ontap/
Comment: It is obvious
Comment: These simple options will help you achieve a robust, scalable, and highly available architecture for your web application
Comment: B and C for high availability and scalability
Comment: correct Answer is B& C as it talks about high availability and scalability and rest of the options are for Disaster Recovery. Right answer is B & C.
Comment: correct Answer is B& C as it talks about high availability and scalability and rest of the options are for Disaster Recovery. Right answer is B & C.
Comment: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html
Comment: Answer is DE
Comment: B is correct and C, D is incorrect since the auto scaling is working within Region not Multi region. E incorrect also because the question is asking a high availability C is the best answer that E.
Comment: D doesn't provide automatic rotation Answer will be B and C
Comment: C. Store sensitive information in AWS Secrets Manager. AWS Secrets Manager securely stores sensitive information and provides automatic rotation of secrets, reducing the need for manual management. B. Create a Lambda layer that retrieves sensitive information. Using a Lambda layer allows multiple Lambda functions to access the sensitive information stored in Secrets Manager without needing to duplicate retrieval logic in each function. This approach centralizes the retrieval process and reduces operational complexity.
Comment: chatgpt answer is now C and D
Comment: AWS public documentation and other professional forums instead, kindly!
Comment: BC is correct
Comment: B,C ChatGPT agrees with me
Comment: Answer is CD
Comment: https://docs.aws.amazon.com/systems-manager/latest/userguide/ps-integration-lambda-extensions.html https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/using-aws-secrets-manager-and-lambda-function-to-store-rotate-and-secure-keys/
Comment: C looks right
Comment: Answer is C
Comment: https://aws.amazon.com/compute-optimizer/ https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html
Comment: Answer is D
Comment: D is the right answer
Comment: Answer is B Since the read replica is now underutilized with only 25% CPU usage, it can be resized to a smaller instance to save costs while still handling the reduced read queries. No changes to the primary instance are needed, as it is consistently running at 60% CPU usage, which is manageable, and the read replica will still offload read queries in the future.
Comment: No clear explanation here and everyone agreed with default answer
Comment: B looks good
Comment: Answer is B
Comment: Resize the read replica to a smaller instance size Do not make changes to the primary instance
Comment: the longer the reservation the more the savings too for reserved
Comment: D is right
Comment: Correct Answer - D, All upfront is cheaper than partial and no upfront.
Comment: D is correct
Comment: letter D is the correct, It gives you big discount if you purchase with all upfront
Comment: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html => DE
Comment: probably D and E https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html
Comment: chatgpt: D. Define an IAM role that includes the necessary permissions. Annotate the Kubernetes service accounts with the Amazon Resource Name (ARN) of the IAM role: Granular Access Control: By defining an IAM role with the necessary permissions and annotating the Kubernetes service accounts with the ARN of this IAM role, you can achieve fine-grained access control for specific AWS resources. This allows each service account to have only the permissions it needs. E. Set up a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider: IRSA Integration: To enable IRSA, your EKS cluster must be associated with an OpenID Connect (OIDC) identity provider. This trust relationship allows Kubernetes service accounts to assume IAM roles, enabling secure and granular access to AWS resources.
Comment: my educated guess C, E
Comment: SSE keys provided usage fee application and there is no monthly charges, hence its a correct option. D is highly cost option with monthly and usage fee. which is incorrect.
Comment: D auto-rotation feature > customer managed key
Comment: D. customer needs to see the logs from Cloudtrail!
Comment: Even with AWS KMS keys, rotation is logged on ctrail. Answer is D. https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#:~:text=Monitoring%20key%20rotation,key%20was%20rotated.
Comment: Answer is C. There is no monthly fee for AWS managed keys https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk
Comment: Customer managed key: Monthly fee (pro-rated hourly) + Per-use fee + rotation and cloudtrail AWS managed key: No monthly fee + Per-use fee (some AWS services pay this fee for you)+ rotation and cloudtrail
Comment: D gives you control, allows you to customise for example rotation policies to suit your compliance needs.
Comment: Answer is D
Comment: - Organizing and tracking costs using AWS cost allocation tags https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html - Cost Explorer uses the same dataset that is used to generate the AWS Cost and Usage Reports and the detailed billing reports. For a comprehensive review of the data, you can download it into a comma-separated value (CSV) file. https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
Comment: cost explorer allows cost analysis of up to 13 months.
Comment: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
Comment: c looks good
Comment: B is the answer
Comment: B is the answer
Comment: B is correct
Comment: C sounds right
Comment: Inspect traffic for that use GWLB OPTION C
Comment: Answer is C
Comment: https://docs.aws.amazon.com/vpc/latest/privatelink/create-gateway-load-balancer-endpoint-service.html
Comment: Custom Endpoints: Custom endpoints in Amazon Aurora allow you to group specific replicas together and route traffic only to those replicas. This is particularly useful when you have replicas with different compute and memory specifications and want to direct specific workloads, such as reporting queries, to those replicas. By creating a custom endpoint, you can include the three specific Aurora Replicas that have the required compute and memory configurations, ensuring that your near-real-time reporting queries are automatically distributed among these replicas.
Comment: Answer is B
Comment: Secrets Manager: AWS Secrets Manager is specifically designed to store and manage sensitive information like database credentials. It provides built-in functionality for securely storing, retrieving, and automatically rotating credentials. Automatic Rotation: Secrets Manager can be configured to automatically rotate the database credentials at regular intervals (e.g., every 30 days). This reduces operational overhead by eliminating the need for manual credential rotation or custom rotation logic. Integration with Lambda: Lambda functions can easily retrieve credentials stored in Secrets Manager by calling the Secrets Manager API, which simplifies the application code and enhances security.
Comment: B. Create an AWS DMS Serverless replication task to analyze and replicate the data while provisioning the required capacity. Explanation: AWS DMS Serverless is designed to automatically allocate and manage the necessary compute and memory resources based on the demand of the data replication workload. It scales capacity up or down according to the data replication requirements without manual intervention. This approach ensures that the replication task uses only the required capacity at any given time, optimizing costs and resources, especially given that the amount of data to replicate varies throughout the day.
Comment: correct answer could be "B"
Comment: Answer is A
Comment: Correct answer is B since the question need to allocate only the capacity that the replication instance requires
Comment: https://docs.aws.amazon.com/prescriptive-guidance/latest/integrate-third-party-services/architecture-1.html It is limited to only TCP traffic and unidirectional communication. The third-party workloads cannot initiate communication back to your account.
Comment: I think C is corret 2. Restrict Inbound Traffic via Security Groups: To prevent the third-party SaaS provider from establishing inbound connections to your VPC, use Security Groups attached to the VPC Endpoint Interface. Outbound Traffic Allowed: Ensure that your security groups allow outbound traffic to the SaaS provider's IP ranges or endpoints. Restrict Inbound Traffic: You should block all inbound traffic on the VPC Endpoint Interface by configuring the security group rules. For example: Inbound Rules: Block all traffic (or leave it empty). Outbound Rules: Allow outbound connections to the IP addresses or ports specified by the SaaS provider.
Comment: Answer is D
Comment: D is correct
Comment: This is C, but not for all the reasons everyone is posting. D, also encrypts traffic and works at the network layer and also has security controls to prevent unrestricted access between AWS and on-premises systems. So, if you thought D like I did initially you were very close. The reason it is C, is because C works at both the network and session layer while doing all the other requirements as well. Where as D only works at the network layer. Happy studying!
Comment: C is correct
Comment: AWS Direct Connect does not provide encryption by itself; it is often used in conjunction with VPN for encrypted traffic. Direct Connect primarily offers a dedicated connection and does not inherently satisfy the encryption requirement.
Comment: Answer is D
Comment: C is correct question needs to access between on prem and AWS
Comment: AWS Secret manager securely stores data base user id and passwords
Comment: C Explanation: AWS Secrets Manager is designed specifically for managing and automatically rotating credentials, including database credentials, API keys, and other secrets. It provides a secure and centralized place to store credentials and allows applications to retrieve them securely without hardcoding them in the application. Secrets Manager also offers built-in support for automatic rotation of credentials using Lambda functions, which reduces the manual effort needed for rotation and enhances security. This approach requires minimal programming effort because the application only needs to be configured to retrieve the credentials from Secrets Manager instead of being embedded within the application code.
Comment: Answer is C
Comment: A is correct
Comment: A wins because it gives us encryption with AWS KMS multi-Region keys
Comment: Answer is A
Comment: C is correct because it needs to replicate to different AWS region
Comment: this is A S3 Glacier Deep Archive is the most cost-effective storage for long-term infrequently accessed data, ideal for the user-uploaded images used twice a year for AI training. S3 Standard for premium user-generated AI images ensures fast access, which is needed for frequent downloads. S3 Standard-IA for non-premium user-generated AI images is cost-effective for less frequent access, as it charges lower for storage but slightly more for retrieval, which fits the 6-hour download frequency. Not C because, although S3 One Zone-IA is a lower-cost option as well it provides less durability because it stores data in only one Availability Zone. While it is cost-effective, it increases the risk of data loss for critical AI training data. B and D is out S3 Glacier Flexible Retrieval for all generated AI images would likely introduce unacceptable retrieval delays for premium users, as they require immediate access to download images
Comment: This is A. We care about cost effectiveness. In regards to images being used twice a year "For images accessed only twice a year, S3 Glacier Deep Archive would be the more cost-effective option compared to S3 One Zone Infrequent Access, as it is designed for extremely infrequent access and offers the lowest storage cost within AWS S3 storage classes; while S3 One Zone Infrequent Access is cheaper than standard Infrequent Access, it still might be slightly more expensive for data accessed as rarely as twice a year." In regards to premium users keep them standard. Non premium users can be in the infrequent since they have 6 hrs. Cost Effective!
Comment: S3 Glacier Deep Archive does not meet the 6-hour download requirement because it takes time to access data. User can download even if you are not a premium user
Comment: it says "Users can download the generated AI images once every 6 hours." The upload images are used for training only 2 times a year which meets the s3 glacier deep dive. The standard users are put in infrequent access and premium users are put in standard. I don't understand how people are messing this up.
Comment: The company uses the user-uploaded images to run AI model training twice a year. So for this Deep Archive will be ncessary.
Comment: B is correct Explanation: S3 Glacier Deep Archive is the most cost-effective storage option for data that is rarely accessed. Since the user-uploaded images are only used twice a year for AI model training, storing them in Glacier Deep Archive is ideal for minimizing costs. The longer retrieval time (up to 12 hours) is acceptable given the infrequent access. S3 Glacier Flexible Retrieval is suitable for storing the generated AI images because it balances cost and retrieval time. Regular users can download images every 6 hours, which Glacier Flexible Retrieval can accommodate with its flexible retrieval options (ranging from minutes to hours). This solution also works for premium users, who might need more frequent access. While S3 Standard or Standard-IA could be used, Glacier Flexible Retrieval offers significant cost savings while still meeting the access requirements.
Comment: S3 One Zone-IA is a cost-effective storage option for images that are accessed infrequently but are still needed for AI model training twice a year. One Zone-IA stores data in a single Availability Zone, making it less expensive but still highly available within that zone. Premium users need frequent access to their AI-generated images so S3. Non-premium users access their AI-generated images less frequently (once every 6 hours) so S3 Standard-IA
Comment: A is correct as Glacier deep archive provides the lowest-cost storage class.
Comment: Why should I use SQS in option D? Wouldn't ALB be enough?
Comment: D is the answer: SQS Queue: Directing API requests to SQS decouples the API from ML processing, efficiently handles high traffic, and ensures reliable request processing without overloading the ML models. Amazon ECS Services: Running ML models on ECS provides effective management of containerized applications, ideal for handling ML workloads. Auto Scaling: ECS auto scales based on SQS queue size, adjusting container and cluster capacity to match demand, ensuring efficient handling of varying workloads.
Comment: It can be A, if minimum value = 0. It Can be D, if this approach is implemented before the disaster. And "Set the Auto Scaling group desired capacity to zero" means that it supposed to be done before the disaster.
Comment: https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html The DR solution does not need to support customer usage when the primary infrastructure is healthy. -> Pilot Light
Comment: Backup and restore RTO is up to hours
Comment: RTO 30 minute, warm standby.
Comment: https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-s3-glacier-instant-retrieval-storage-class/ - The easiest way to store data in S3 Glacier Instant Retrieval is to use the S3 PUT API to upload data directly, or use S3 Lifecycle to transition data from the S3 Standard and S3 Standard-IA storage classes. - The company wants to keep the cost of running the application in the AWS Cloud as low as possible => B
Comment: D looks right
Comment: D is correct
Comment: D is the correct answer for 30 days - use Amazon S3 standard 2 years Retaining - Glacier Deep Archive Can not be Disrupted - On-Demand Instances
Comment: I understand that D is the right anwser
Comment: I VOTE C
Comment: you voted wrong
Comment: Job cannot be disrupted - On demand
Comment: Question asked about cheapest. D is not cheap
Comment: BD sounds right
Comment: BD is correct
Comment: Answer is A
Comment: A. Create an Amazon RDS Proxy. Assign the proxy to the DB instance. Explanation: Amazon RDS Proxy: RDS Proxy is designed to manage connections to the database more efficiently. It can reduce the impact of failovers on the application by maintaining connections and transparently rerouting them to the standby instance during a failover event. By using RDS Proxy, the failover time is reduced because the proxy minimizes the disruption that occurs when the database fails over, thus reducing application timeouts.
Comment: While AWS Systems Manager State Manager can be used to manage configuration states of AWS resources, it is generally more complex to set up for straightforward use cases like schedule-based starting and stopping of RDS instances compared to using a direct scheduling method through EventBridge.
Comment: Start, restart, or stop managed nodes and Amazon Relational Database Service (Amazon RDS) instances.
Comment: D. Amazon EventBridge allows you to create rules based on a schedule (using cron expressions) to automate tasks. You can set up rules to start the RDS instances at the beginning of business hours and stop them at the end of business hours. By using AWS Lambda in conjunction with EventBridge, you can create functions that handle
Comment: VOTE D
Comment: To meet the requirement of running Amazon RDS DB instances only during business hours with the least operational overhead, the best solution would be: D. Create an Amazon EventBridge rule that invokes AWS Lambda functions to start and stop the RDS instances. This approach allows you to automate the scheduling of start and stop actions using EventBridge rules, which can trigger Lambda functions based on a cron expression. This setup is straightforward and requires minimal ongoing management
Comment: Option C, which involves using AWS Systems Manager State Manager to start and stop the RDS instances, is indeed a viable solution. It allows you to automate the process of keeping your RDS instances in a desired state, such as starting and stopping them on a schedule12. However, the reason Option D (using Amazon EventBridge with AWS Lambda) might be preferred for this scenario is due to its simplicity and flexibility. EventBridge rules can be easily configured with cron expressions to trigger Lambda functions, which can start and stop the RDS instances. This setup typically involves fewer steps and less configuration compared to setting up State Manager associations and IAM roles3. Both options are valid, but Option D generally offers a more straightforward approach with potentially lower operational overhead
Comment: AWS Systems Manager State Manager allows you to automate the process of starting and stopping RDS instances based on a defined schedule.
Comment: Answer is D
Comment: Correct Answer us C - it allows you to define and automatically enforce desired configurations for EC2 and RDS.
Comment: A. Configure the Requester Pays feature on the company's S3 bucket. Explanation: A. Configuring the Requester Pays feature on the company's S3 bucket is the most appropriate solution. With Requester Pays, the marketing firm's AWS account will be responsible for the data transfer costs when accessing the data in the S3 bucket, minimizing the data transfer costs for the consumer survey company. B. Configuring S3 Cross-Region Replication (CRR) from the company's S3 bucket to one of the marketing firm's S3 buckets would not be the most cost-effective solution, as the company would still be responsible for the data transfer costs.
Comment: The Requester Pays feature allows the bucket owner to offload the data transfer costs to the requester. When this feature is enabled, the marketing firm would pay for the data transfer when they access the data in the survey company's S3 bucket, which effectively minimizes costs for the survey company. This means that the most cost-effective solution for the survey company, given that the marketing firm is accessing the data, is "A"
Comment: Answer B seems to be more logic, the question didn't mention which account will pay
Comment: question ask for method to reduce cost in survey company, so A will do it
Comment: A sounds right
Comment: Letter A
Comment: A is the correct answer https://docs.aws.amazon.com/AmazonS3/latest/userguide/RequesterPaysBuckets.html
Comment: WAF can be applied on ALB, API gateway or cloud front.
Comment: Answer is C. Note: AWS Global Accelerator itself doesn't support AWS WAF. https://repost.aws/knowledge-center/globalaccelerator-aws-waf-filter-layer7-traffic
Comment: Configuring the WAF directly on the Global Accelerator ensures that malicious traffic is blocked before it reaches the Application Load Balancer, providing an additional layer of protection.
Comment: C as AWS WAF cannot be used directly on global accelerator
Comment: Global Accelerator can be integrated with AWS WAF to provide protection at the edge, meaning malicious traffic can be blocked before it reaches your Application Load Balancer (ALB) or other resources in your AWS environment.
Comment: Answer is A AWS Global Accelerator (GA) can be used with AWS Web Application Firewall (WAF) to protect applications from web exploits and DDoS attacks: Block HTTP method and header attacks GA, WAF, and the Application Load Balancer can block access to Layer 7 HTTP method and headers. WAF uses web access control list (web ACL) rules with the load balancer to evaluate incoming traffic and only forward requests that comply with the rules to the endpoint. Detect and mitigate web application layer request floods GA can protect web applications running on Application Load Balancer, and when used with WAF, it can also detect and mitigate web application layer request floods. Prevent DDoS attacks
Comment: Answer is A
Comment: Correct answer C. Global Accelerator does not work with WAF as it is suitable for TCP/UDP where as WAF is integrates with Application Load Balancer which is on Layer 7 on OSI model, suitable for Web app (Http/Https)
Comment: https://aws.amazon.com/blogs/big-data/accelerate-amazon-dynamodb-data-access-in-aws-glue-jobs-using-the-new-aws-glue-dynamodb-elt-connector/
Comment: The DynamoDB export connector allows you to export data from DynamoDB to other storage solutions like Amazon S3 without consuming the table's provisioned read capacity, ensuring minimal impact on the performance of the table.
Comment: B. Instead, the new AWS Glue DynamoDB export connector reads DynamoDB data from the snapshot, which is exported from DynamoDB tables. This approach has following benefits: It doesn't consume read capacity units of the source DynamoDB tables
Comment: DynamoDB export connector literally "exports" table snapshot to s3 as dynamoDB-json object, then process on it. So it does not affect on read / write capacity on dynamoDB itself. But Athena query directly on dynamoDB so affects on read / write capacity
Comment: To calculate performance metrics for customer device data on a daily basis with minimal effect on the table's provisioned read and write capacity, the best solution would be: A. Use an Amazon Athena SQL query with the Amazon Athena DynamoDB connector to calculate performance metrics on a recurring schedule. This approach allows you to run SQL queries directly on the data stored in DynamoDB without impacting the provisioned throughput, as Athena queries are serverless and do not consume DynamoDB read or write capacity1.
Comment: The right answer is B
Comment: VOTE B
Comment: why is B wrong.. Glue DynamoDB export connector will read data from PITR instead of DynamoDB directly..
Comment: I go with A
Comment: Answer is C: SQS is your first cue then scaling based on the number of requests
Comment: "Based on the number of jobs that need to be processed"
Comment: D is right
Comment: D gives us a server-less solution which is what we want.
Comment: D sounds right
Comment: If the answer is B, how will the data be encrypted before being stored in Amazon S3? It has to be client-side encryption.
Comment: AWS handles the encryption and decryption process, simplifying the management of encryption keys.
Comment: If client-side encryption is used, the keys must be managed by the customer.
Comment: Correct is A
Comment: Before you store the data in S3 you can use client side encryption
Comment: B. Creating EMR runtime roles and configuring the cluster to use them is the correct solution. EMR runtime roles allow you to grant specific permissions to the big data workloads, ensuring that each team's workloads can only access the required AWS services. Additionally, the runtime roles can be configured to disable access to IMDSv2, meeting the requirement.
Comment: This approach avoids the need for workloads to access the Instance Metadata Service (IMDSv2) on the underlying EC2 instances, as the permissions are managed through the runtime roles.
Comment: Explanation: EMR Runtime Roles: By creating EMR runtime roles, you can assign specific IAM roles to individual EMR jobs or steps. Each role can have fine-grained permissions, allowing you to restrict access to only the AWS services each team needs. This provides a highly controlled environment where each team's workload operates under the principle of least privilege. IMDSv2 Access: When using runtime roles, you do not rely on the EC2 instance profile for service access, thereby minimizing the need for the workloads to access the Instance Metadata Service. This can help in reducing the risk of unauthorized access to IMDSv2.
Comment: Unlike standard queues, FIFO queues don't introduce duplicate messages. FIFO queues help you avoid sending duplicates to a queue. If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues-exactly-once-processing.html
Comment: Keywords in the qsn (quickly and once) = SQS FIFO
Comment: A is correct
Comment: Answer is A
Comment: Keyword "streaming" hence Amazon Kinesis Data Streams as it is designed for real-time data ingestion and processing, making it ideal for collecting streaming data from various producers.
Comment: D sounds right
Comment: Answer is D using Amazon Kinesis Data Streams, Amazon OpenSearch Service, and Amazon QuickSight provides a comprehensive and AWS-native solution that meets the requirements of real-time data ingestion, search, and visualization
Comment: Meets all requirements.
Comment: A gives us a serverless solution
Comment: AWS App2Container: This service helps you easily containerize existing applications, such as your ASP.NET application, reducing the complexity of the containerization process. Amazon ECS on AWS Fargate: Fargate is a serverless compute engine for containers that eliminates the need to manage the underlying EC2 instances, significantly reducing operational overhead. You only need to focus on your containerized application, while AWS handles the infrastructure.
Comment: https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html
Comment: Option D is similar to option B, but option B unnecessarily introduces AWS Batch into the solution. AWS Batch is designed for executing batch jobs and is not required for the use case of retrieving secrets in a web application. This adds complexity and overhead without benefit.
Comment: respuesta correcta D : La opción D proporciona una solución adecuada y segura para gestionar y recuperar secretos, con un enfoque en la menor sobrecarga operativa posible al utilizar AWS Secrets Manager junto con la API correcta y la integración con AWS CloudFormation.
Comment: Answer is A. Amazon FSx for Windows File Server provides fully managed shared storage designed for Windows workloads. It offers seamless integration with Windows applications and supports Windows Server Failover Clustering (WSFC), making it the ideal choice for clustering applications. High availability is provided as the cluster spans multiple Availability Zones, ensuring that the application continues to function in case of an AZ failure. Low-latency access to shared block storage is achievable with FSx, and it reduces the complexity compared to setting up replication between multiple Amazon EBS volumes. Least implementation effort: You don't need to manage block-level replication or create complex replication setups between AZs, as FSx for Windows File Server handles this automatically. It simplifies storage management and offers native Windows support.
Comment: Using Amazon FSx for Windows File Server would not be the best solution, as the company requires block storage, not file storage. D. Deploying the application on EC2 instances and using Amazon EBS Provisioned IOPS SSD (io2) volumes with EBS-level replication is the solution with the least implementation effort for the following reasons: EBS volumes provide the required block storage for the application. Using EBS-level replication to sync data between Availability Zones is a built-in feature, requiring less implementation effort compared to setting up custom replication mechanisms. Provisioned IOPS SSD (io2) volumes ensure the low-latency access to the block storage required by the application. By using Amazon EBS Provisioned IOPS SSD (io2) volumes with EBS-level replication, the company can meet the requirements for high availability and low-latency access to block storage with the least implementation effort.
Comment: block storage -> B or D io1, io2 support EBS Multi-Attach -> D
Comment: Key word in the question is block storage which eliminates A as a possibility. FSx for NetApp ONTAP provides low-latency block storage, multi-AZ high availability, and requires the least implementation effort because it is a fully managed service with built-in replication and failover capabilities. This makes it the most suitable and cost-effective option for the company's needs.
Comment: Amazon FSx for NetApp ONTAP also provides shared block storage over the iSCSI and NVMe-over-TCP protocols. Seems to be a complete match there.
Comment: For those who are choosing option other than A: what part of "with the LEAST implementation effort" do you not understand?
Comment: The part where it calls for block storage.
Comment: Answer is B EFS is not Block Storage, EBS is.( Thus, A and C are out)
Comment: due to this line in question "low-latency access to block storage" C looks appropriate.
Comment: A - Windows cluster across two availability zones satisfies highly available condition and FSx satisfies storage access from multiple ec2 especially for Windows server. B - "Set up application-level replication to sync data" not for LEAST effort condition C, D - "in standby mode" need to be activated manually so its not highly available
Comment: Block storage
Comment: Changed for C, bc application-level replication is more difficult to implement.
Comment: Windows = FSX
Comment: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-update-security-groups.html The following rules are recommended for an internet-facing load balancer.
Comment: This question is poorly worded: assuming that, by default in security groups, all OUTBOUND connections are ALLOWE and all INBOUND connections are DENIED, options C and E would not even need to be configured. What would be needed is to create a security group for the EC2 instances allowing INBOUND connections from the ALB security group to the EC2 instances security group on ports 443 and 8443.
Comment: A. This allows the ALB to receive HTTPS traffic from the public internet. C. This ensures that the ALB can send HTTPS traffic to the web application servers. E. This allows the ALB to perform health checks on the web application servers over HTTPS on port 8443.
Comment: A. This allows the ALB to receive HTTPS traffic from the public internet. C. This ensures that the ALB can send HTTPS traffic to the web application servers. E. This allows the ALB to perform health checks on the web application servers over HTTPS on port 8443.
Comment: Answer is ACE
Comment: A. Allow HTTPS inbound traffic from 0.0.0.0/0 for port 443. This allows the ALB to receive HTTPS traffic from the public internet on port 443. C. Allow HTTPS outbound traffic to the web application instances for port 443. This allows the ALB to forward HTTPS traffic to the web application servers on port 443. E. Allow HTTPS outbound traffic to the web application instances for the health check on port 8443. This allows the ALB to perform health checks on the web application servers over HTTPS on port 8443.
Comment: Correct is BD
Comment: Amazon CloudFront requires an SSL/TLS certificate to use HTTPS with a custom domain name. This certificate MUST be provisioned in the us-east-1 Region, regardless of where your content is hosted. This is because CloudFront only supports certificates in the us-east-1 Region for use with custom domain names. Origin Access Control (OAC) is a feature that allows you to securely upload content to an S3 bucket using CloudFront. It provides fine-grained access control and ensures that only CloudFront can upload files to the S3 bucket, preventing direct access. Configuring S3 to allow uploads from CloudFront using OAC ensures that only CloudFront can interact with the S3 bucket, adding an extra layer of security.
Comment: AWS Region for AWS Certificate Manager To use a certificate in AWS Certificate Manager (ACM) to require HTTPS between viewers and CloudFront, make sure you request (or import) the certificate in the US East (N. Virginia) Region (us-east-1)
Comment: cloud front require all SSL certificate to be in us-east region regardless the origin location of the site server.
Comment: AD looks correct
Comment: A. Use AWS Certificate Manager (ACM) to create a public certificate in the us-east-1 Region. Use the certificate in CloudFront: CloudFront requires the certificate to be in the us-east-1 Region for custom domain names. D. Configure Amazon S3 to allow uploads from CloudFront origin access control (OAC): This ensures secure uploads from CloudFront to the S3 bucket.
Comment: A. Use AWS Certificate Manager (ACM) to create a public certificate in the us-east-1 Region. Use the certificate in CloudFront. CloudFront requires that the SSL/TLS certificate for the custom domain be created in the us-east-1 Region (N. Virginia). Even if your S3 bucket is in another region, the certificate must be in us-east-1 because CloudFront is a global service and this region is where CloudFront looks for certificates. D. Configure Amazon S3 to allow uploads from CloudFront origin access control (OAC). Configuring S3 to allow uploads from CloudFront using Origin Access Control (OAC) ensures that only CloudFront can interact with your S3 bucket, improving security by preventing direct access to the bucket from the public internet.
Comment: Answer is AD
Comment: BD correct answer
Comment: A. Athena would be overkill and more expensive for simple queries on specific files. C. Amazon Redshift with Redshift Spectrum would be significantly more complex and costly to set up and maintain for occasional queries. D. EMR Serverless with Apache SparkSQL would also be more complex and likely more expensive for this use case. S3 Select provides the right balance of functionality and cost-effectiveness for the described scenario, making it the most suitable choice
Comment: A is my choice.
Comment: A sounds right
Comment: Athena for sql
Comment: Correct answer is A Geo location is based on users location GeoProximity is based on the AWS services used by users.
Comment: Correct answer is B!
Comment: The answer is A. routing traffic to the user region. Also, it can't be B. It says using a Network Load Balancer. you can't use a network load balancer for internet traffic
Comment: Correct answer is A
Comment: It is B: Geolocation: Primarily focuses on the user's location, allowing you to serve different content based on their geographic region. Geoproximity: Considers both the user's location and the location of your resources, dynamically choosing the closest option based on network latency.
Comment: Keyword closest. Amazon Route 53 Geoproximity Routing: This routing policy directs traffic based on the geographic location of your users and your resources, ensuring that users are routed to the closest EC2 instances.
Comment: Geolocation Routing Policy - Routes traffic based on the geographic location of the users. Geoproximity Routing Policy - Routes traffic based on the geographic proximity of the user to AWS resources.
Comment: Answer is B
Comment: Amazon RDS for MySQL supports encryption at rest using AWS Key Management Service (KMS) managed keys. This encryption is easy to enable during the creation of the RDS instance and requires minimal configuration. AWS KMS provides a fully managed solution for managing encryption keys, and using KMS managed keys reduces operational overhead related to key management and rotation. Encryption in transit ensures that data transmitted between the application and the RDS database is secure. AWS Certificate Manager (ACM) can be used to provide SSL/TLS certificates, which are required to encrypt data in transit. ACM simplifies the management of SSL/TLS certificates by handling certificate renewal and deployment, reducing operational overhead.
Comment: A is my choice anyday.
Comment: A is correct
Comment: https://aws.amazon.com/getting-started/hands-on/amazon-rds-backup-restore-using-aws-backup/
Comment: A: Amazon RDS automated backups support a maximum retention period of 35 days. This option does not meet the requirement to retain backups for 90 days. B: This approach requires manual snapshot management, including scheduling snapshots and deleting old ones. This increases operational overhead and is prone to human error. C: This option is not applicable as Aurora Clone is a feature specific to Amazon Aurora and not available for Amazon RDS for Oracle. Additionally, it would require manual management of clones, increasing complexity. D: AWS Backup supports point-in-time recovery for Amazon RDS, enabling you to restore the database to any specific point within the defined retention period, up to 35 days. For the requirement of 14 days, AWS Backup easily supports this capability.
Comment: D is right
Comment: Correct Answer is D - Its fulfilling the requirement of point in time. Automated Backup - Default retention period is 0-35 Days - so option A is wrong.
Comment: Answer is D
Comment: B looks good
Comment: B is my choice.
Comment: Answer is C. Just specify only the company AWS account number, rather than listing all the Buckets
Comment: Vote A
Comment: VOTE A
Comment: la respuesta correcta es la A :Los buckets son servicios globales.( o sea no están en una VPC ni Subnet ), entonces no hace falta que estén en una subred publica o privada ; los Nat Gateway son para redes publicas o privadas .Entonces ahí descarta B,C y D .Cuando quieres conectar un recurso de Global Service se usa Endpoint Gateway por eso la respuesta es A .
Comment: B, C is not secure way because NAT gateway is for internet-facing outbound. A is not correct because company will create dedicated bucket for each customers it means number of buckets will increase dynamically. so you cant list all on profile.
Comment: Is there anyone who has recently passed the exam who can tell me approximately how many of the original questions are in the actual exam?
Comment: Option A is goo but not the best, which is option B.
Comment: IAM Identity Center: This service simplifies user management by centralizing credentials and access control. Permission Sets: You can create granular permission sets that align with the principle of least privilege, ensuring that each team has only the access they need. Group Assignments: By assigning teams to groups with specific permission sets, you streamline access management and reduce the complexity of individual user permissions. This approach minimizes operational overhead while maintaining secure and compliant access to sensitive customer data
Comment: Answer is B
Comment: Answer is B. AM Roles Anywhere allows on-premises servers and applications to obtain temporary AWS credentials and access AWS resources securely. This solution allows your on-premises virtual machines to use IAM roles without needing long-term credentials (like access keys). The virtual machines can assume roles and access the S3 bucket temporarily and securely. Since the company is already using AWS IAM Identity Center, using IAM Roles Anywhere allows the company to leverage its existing Identity Center setup while following AWS best practices for security. This approach ensures the application can securely retrieve credentials without embedding static credentials into the application.
Comment: Answer is B
Comment: Answer is D
Comment: Answer is A
Comment: Respuesta correcta B . Los patrones de acceso varían = Nivel inteligente de Amazon S3 .
Comment: Answer is D
Comment: Answer is D
Comment: This is A and B. TCP best option is NLB. I know tons of you want to use chat GPT and it's going to tell you application load balancer, then ask chatgpt if an application load balancer really is the best option for TCP and it will be like "aw dang dawg, its not, you're right". Then it will switch to A and B. Because chatgpt doesn't know everything. It's a great tool but you still need to research because it doesn't have all the answers.
Comment: TCP - NLB
Comment: This is C, you are looking for the most cost effective solution. Again if any of you use ChatGPT it will say A because it makes the most sense for automation and less management. But it is not the most cost effective. AWS Backup costs extra money. So A, is not correct. It is C.
Comment: Agree! Additionally we can configure RDS backup easily for a built-in 30 days retention, which meets the requirement and less cost than using AWS backup service
Comment: D makes more sense, since AWS CF will keep last 30 days from now on.
Comment: .respuesta correcta A-D : Para cumplir con los requisitos de etiquetado de instancias de Amazon EC2 con sensibilidad de datos y garantizar que las identidades de IAM no puedan eliminar una etiqueta o crear instancias sin una etiqueta, la combinación de pasos más adecuada es: A. En Organizaciones, cree una nueva política de etiqueta que especifique la clave de etiqueta de sensibilidad de datos y los valores requeridos. Aplica los valores de etiqueta para las instancias de EC2. Adjunte la política de etiquetas a la OU apropiada. D. Cree una política de control de servicio (SCP) para denegar la creación de instancias cuando no se especifica una clave de etiqueta. Crea otro SCP que evite que las identidades eliminen las etiquetas. Adjunte los SCP a la OU apropiada.
Comment: Answer is C
Comment: This is a tough one I would say. I wish B and C can combine. but I vote for B. For B, it is more cost efficiency focus rather than decoupling the whole process for improving overall reliability. For C, the use of SQS is perferct solution for the downside of option B. But EC2 comes in picture which increases the cost and operational complexity. How to pick then? lets go back to the question and see what it focuses - cost or operational compllexity and stability? It looks like it leans more on focusing scalibility and cost-efficiency. In that case, I would go for B because fargate provides cost-efficiency and store just metadata in DB and the rest data in S3 also provides a lower cost and improves its performance.
Comment: Additionally, C also introduced ALB service in the picture, that increases the cost as well.
Comment: C makes the most sense out of the options and given requirements.
Comment: Answer: C The question did not mention the application need to be containerized , i will choose C
Comment: S3 Intelligent-Tiering is cost-effective for storing large amounts of video content, and since Lambda doesn't work, shouldn't we consider serverless?
Comment: I personally think C, I could be wrong.
Comment: Respuesta correcta C = AWS Fargate = menor sobrecarga operativa. A, B y D tienen gestión de infraestructura.
Comment: Respuesta correcta C = AWS Fargate = menor sobrecarga operativa . A , B y C tienen gestión de infraestructura .
Comment: Answer is B
Comment: Question says, "Apps must be able to retrieve frequently accessed data with low latency" so we go with cached volumes. We'd have chosen the stored volumes if question was about low-latency access to the entire dataset.
Comment: Block storage use volume gateway, low latency use store volumes.
Comment: Respuesta correcta B . Baja latencia = Elastic Cache . A , C y D no cumplen un acceso con baja latencia ( descartados ) .
Comment: D. Use DynamoDB global tables for automatic multi-Region replication. Deploy tables in multiple AWS Regions. Use provisioned capacity mode. Enable auto scaling. Explanation: DynamoDB global tables automatically replicate data across multiple Regions, ensuring that the data is available and consistent across all Regions. This provides resilience and high availability by allowing users in different geographical locations to access data from the closest Region. Provisioned capacity mode allows you to pre-allocate read and write capacity units, which can result in cost savings over on-demand capacity mode if the traffic is predictable. Additionally, auto scaling can be enabled to dynamically adjust the capacity based on the actual traffic, ensuring that you only pay for the capacity that you need. Multi-Region deployment improves the resilience of the system. If a failure occurs in one Region, another Region can seamlessly take over, ensuring an uninterrupted gaming experience.
Comment: B. Configure an Amazon S3 File Gateway to provide storage for the on-premises application. Explanation: Amazon S3 File Gateway provides a way for on-premises applications to access objects stored in Amazon S3 as files. It caches frequently accessed data locally, which ensures low-latency access to the data. This is crucial for maintaining the performance of the rendering application. By keeping the data in Amazon S3, the company benefits from lower storage costs compared to using other storage services like Amazon FSx, while still providing the necessary performance for the on-premises application through the local caching capabilities of the File Gateway. The File Gateway seamlessly integrates with Amazon S3, allowing the application to access data using standard file protocols like NFS or SMB, which simplifies the setup.
Comment: CloudFront for Dynamic content (such as API acceleration and dynamic site delivery)
Comment: CloudFront can reduce response times by caching API responses, but if the API is dynamic and not cacheable, it may not be as effective. Global Accelerator is better for improving latency when caching is not an option.
Comment: AWS Glue for ETL, then AWS KMS (CSE-KMS)
Comment: AWS Glue with client-side encryption using AWS KMS (CSE-KMS) provides the required pre-processing encryption with minimal operational effort.
Comment: It's C gotta use glue and since it's before the company stores the data in Amazon S3 gotta be client side.
Comment: I say C, aws glue reduces the operational management uses server side encryption and ins which allows for user specific keys.
Comment: reduce cost https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html
Comment: Answer is D
Comment: standard reserved instance is cheaper than convertible reserved instance
Comment: Answer is B
Comment: Answer is A
Comment: Answer is B
Comment: https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html#service-accounts-iam
Comment: OMG finally I have reached here
Comment: Finally made it. Congratulations to everyone who got here. I know the journey has been hard and long. best of luck
Comment: answer B